阿里云好像有个私有专线，在弹性公网 IP 那个里面可以选择加速服务，跨境流量可以直接走阿里云专线直通，不知道会不会过墙…

二维鸡没有噱头，区块鸡才能火

那啥…逗号和句号挺好用的，不考虑用一下吗？😂

🐮🍺，低体脂太重要了，这前后两个状态简直不是同一个人…

@ksc010 #36 不会不够用，分区+同方向的合并到一个线上就好了，这种做法已经被探索得很成熟了的。

@pcbl #15 还好吧，现在 Go 的爬虫框架生态也起来了，简单需求即使没自己的框架，用现成的框架也不会多花多少时间，核心设计都大同小异。要是需求再简单点，那写都没必要写了，直接傻瓜式爬虫工具不香吗😂。

@iyear #13
其实不是的，个人或者小公司按你说的这么玩玩还行，对于业务盘子大点的公司而言，即使是只有针对少量平台的垂直爬虫，但凡有点要求就会得要高并发，避不开的。而反爬，反而是在摸清楚阈值之后（在每个请求 /请求链都模拟得足够像真实用户的前提下）靠着堆账号、堆 IP 、堆设备就能轻松横向扩展解决的事情，无非就是钱的问题而已。单就 IP 方面而言，一个月花一两万甚至更多钱买高质量家宽 IP 的公司其实都不在少数，很多靠数据吃饭的公司都不会吝啬这点投入。

而爬虫库的生态，无论是对于舆情那种海量网站的情况还是对于少量但高要求平台的情况，也仍然不能算是重点，因为会用到的比较核心的那些库现在在主流编程语言中都是有的，Python 的优势主要在于一些小的库，比如用来判断一个域名是否合法并切分出顶级域名部分的 tldextract 。但小的那些库即使你懒得按着重写一个，也完全可以通过把它弄成接口或 RPC 的方式来使用，毕竟只做这点事情的话 Python 是没啥压力的。

@yanluya #17 还好吧，主要接触过的不同公司的人多

看性能相关的需求选择就行了，2 、3 、4 压根不是爬虫的重点，而且实际这三个部分在不同语言中也都大同小异，所以实际影响选择的只有性能。

Python 的资源占用是必然会比 Go 高的，并且整体的执行速度也比 Go 慢，而请求部分即使用了 asyncio+uvloop+aiohttp 这样的组合也还是会比 Go 慢一些，这都是很显而易见的事情。所以选择起来其实很简单，如果你的并发量或数据时效要求已经达到了 Python 有点资源耗费过高或力不从心的情况，那就果断将部分模块剥离出来用 Go 来做，甚至是完全切到 Go 上做；但如果你只是少量玩玩，那你爱用啥用啥，只要你写着舒服就行。

至于楼上说爬虫不在乎编程语言的性能、只在乎网络 IO 的，很明显都没接触过真正量大的情况...哪怕是就单纯的垂直爬虫搞几个大平台，Python 和 Go 都会出现明显的差距，无论是执行速度还是 CPU 、内存、存储空间占用情况都非常明显。至于网络 IO ？反而不会是重点，因为即使网络方面的速度再慢，靠着高并发也一样可以轻松盖住，这方面你需要担心的仅仅是搞 IP 的钱够不够而已，下行带宽又不贵。

另外，demo 都是 python 的也不是啥显著优势，网上很多这种 demo 的代码都只能说是稀烂，对目标平台的反爬处理更是稀碎，再加上如果是完整流程都 copy 的话必然会涉及到框架的区别问题，而如果只是取请求这种关键部分的话，copy 到 Go 里改一下也一样能用，反正关键逻辑都差不多，费不了多少事...

说实在的，这种面积不算太大且固定位置的情况完全没必要用软硬件结合方案，成本又高用的人又不一定多。又不像停车场找车那样，每个人所处的位置不同，需要动态规划最优路线，地面导引完全够用了。

很多室内定位的啊，关键在于商家、机构出于成本和改造难度问题而不愿意搞，地上贴个导引贴纸或者直接用颜料印上导引它不香吗？

海外的可能可以，国内的出于审查需求、网络环境、人均消费水平问题，基本都会是走服务器中转的，肯定要高度压缩，而不是简单编码一下就发出去。

@Spoter #26 能截图和置顶显示就能做，Android 是随便就能实现的，iOS 的话估计没法置顶显示？

@A1B2C3D4 #25 不是瞎想但是没细想嘛，有些拍脑袋定需求的不就是因为没细想所以才显得好笑吗😂谷歌浏览器的翻译是直接修改文字的，字体当然一致啊，你要是换成正常 OCR 翻译的根本没有一致的情况。

不响应可能是因为你碰到了个不按规范渲染文本甚至是非纯文本展示的网页，这你监控剪贴板也没用啊😂。

刚好刚刚在另一个主题下提到了几种同类情况，你可以看看： https://www.v2ex.com/t/795932#reply24

@locoz #23 补充一下之前收藏的用 AI 仿字体的相关资料：
由风格学习算法自动生成大规模手写字体 https://zhuanlan.zhihu.com/p/24454237
Rewrite: Neural Style Transfer For Chinese Fonts https://github.com/kaonashi-tyc/Rewrite

但是这种都是同语种的情况，也就对字体效果要求非常高的需求才会用到，如果只要简单模仿一下很可能都不需要这么麻烦，拿截图里的字仿一下估计都够了。

实际上真要做的话都不一定需要这么仿出字体来，而是直接让 AI 判断字体库里哪个字体与截图中的更相近，然后直接拿那种字体去显示，效率更高而且还不用担心显示出错。

你说的这种就是 OCR 翻译啊，译文字体尽可能依照原文字体这种功能靠 AI 应该可以实现，不是啥问题，而且很可能已经有人在做或者做出来了。

但是关键问题不在这里…

本身 OCR 就会因为五花八门的字体而存在识别错误的问题，再加上依靠 OCR 方式做必然会出现断句位置错误的问题，这都会导致翻译质量降低。

而且不同语言表述同一个意思的语句可不一定同长度，展示的时候即使是尽可能一样的字体，样子也很难美观。

另外就是有些语言的文字都是奇形怪状的，你要把中文按人家的字体来展示，很可能就会也变成奇奇怪怪的样子了，这使用体验真的好吗？

所以说 @shoaly #1 说你像产品经理说的真没毛病，就很有那味，拍脑袋想需求，感觉没有深入思考过 hhhh 。

---

@A1B2C3D4 #10 实际上有对应的，Google 全家桶里有个叫“Google”的应用，在设为辅助应用后是支持双指按压还是啥方式触发 OCR 翻译的，手机上做这类功能的厂商里我见过最早的就是 Google 。做这事关键难点在于权限，一般的 APP 没权限在后台截图，要不然就有隐私安全问题了...

@xtx #11 字幕组有些甚至是自己做的字体，比如 B 站的哈利波特系列；再极端点的还有做游戏翻译的，有些游戏里的界面文字并不是文本标签而是纯粹的图片，翻译组甚至得按着别人的字体一点一点画出来翻译后的文字...这些都是高定制化产生的效果，不能相提并论的。

@zictos #12 网页现在也走向花里胡哨的路线了，比如有些网页会采用 JS 填出来的文字，而不是按规范在 HTML 中填出来；还有些网页会采用 CSS 来改文字，实际内容和 HTML 里的内容完全不一样；还有些是直接放个渲染后的图片文字；再极端点的还有用 JS 实时渲染出来文字的...这对于浏览器那种依靠读取纯文本的方式做翻译的功能来说简直就是灾难。

还好吧，只要考场的车比较新就很好过，我考驾照那时候刚好赶上考场换新车，听教练说那段时间通过率暴涨…