如果客户端设备都是老设备，可能会在动了这两个设置的情况下出现问题：
1 、安全设置中用了强制 WPA3 （或 WPA3+WPA2 混合，但一般只有非常老的设备才会连 WPA2 都不兼容）
2 、手动设置了使用且仅使用高频段（频道），但客户端设备不支持

容器网络内用端口，对外服务用域名，就完事了

@jdkxnktkdkxod #99 然而单踏板并不等于只用一个踏板，备刹跟动能回收也并不冲突，有强动能回收一样可以备刹。油车之所以要在不需要加速的时候立马把脚放在刹车上，本质原因还是因为松开加速踏板也不怎么掉速度，要微调速度只能踩刹车。

而且备刹的核心在于对环境的观察和预测，关键还是要有防御性驾驶的意识，知道与周围事物保持多远距离、什么情况需要减速甚至准备好急刹，没有这个意识该出事故一样会出事故。

只知道要备刹而不知道为什么要备刹就跟无脑的“开慢点安全”一样蠢，前者造就了不知道多少不会控制车距且前车一开始减速就动不动一脚重刹的奇葩，后者则是造就了不知道多少高速、快速路上远低于车流速度的乌龟。

只能说开了七八年车并不能代表开车水平有多好，反倒是开了七八年车还没搞明白那些耳熟能详的注意事项是为了什么，有点搞笑了。

@jdkxnktkdkxod #80 逆天，高速上碰到前车突然急刹变道的还不够紧急？傻逼行为完全无法预知，减速慢点就撞上去了。

而且事实上这种紧急情况下，有动能回收的车反而优势非常明显，因为只要抬脚就必定减速…

@asdgsdg98 #71 “以非常快的速度减速”说明一下子松太多了，有动能回收的电车本来就不是这么开的，只有油车那种响应慢且松加速短时间内不减速的情况才需要大开大合，电车完全可以做到精细化控制。拿油车的开法开电车，就是出租车刚大批量更换电车时广泛出现的那种情况，乘客极其难受，一下子就晕车了。

@jdkxnktkdkxod #69 我也是开有强动能回收的车的，我平时一样基本是单踏板控制速度，非必要不踩刹车，但我从拿驾照到前段时间第一次换证，期间从未出过一次我造成的交通事故，也从未有过追尾。即使是我在听别人说话，没有把注意力完全放在路况上，前车傻逼到在高速上突然急刹准备变道去匝道，也依然能保持住车距，也从未踩错过踏板。

说白了，人的问题不要赖到车上，再怎么肌肉记忆，只要训练出来的肌肉记忆正确，就不会出问题。

@ZGame #61 确实，正常有强动能回收的电车都是日常靠加速踏板的深浅控制速度，看到前面有必要减速的时候就已经开始慢慢松脚，同时车就开始慢慢减速了，要踩刹车的时候都是早就做好了心理预期的，不存在踩错。而且习惯之后再去开没有动能回收的车就极其难受，松了脚动力都还是几乎一样的，要减速就一定得踩刹车，车速变化频繁的情况下为了确保及时与前车保持匀速，踏板就得换来换去，反而有踩错的可能性。

而极端情况，在没有预期的状态下需要急刹，这纯粹就是看个人了，跟车根本没多大关系。正常来说刹车跟加速踏板踩下去的感觉都不一样，踩的时候只要一感觉到阻力有差别就知道踩错了，但有的人一紧张就是会一脚加速踩到底半天都意识不到踩错了，这 TM 开什么车都没用...

@nzynzynzy #33 开了 2 公里还没事，就是得再等 18 年才能继续开车了是吧 https://i.imgur.com/io2SM1h.png

任务多+tracker 多就会这样，打满 CPU 一个核但是一直卡着，之前碰到过一次

会，需要手动排除

然而你拿非 ECC 内存一样可以 7*24 不关机、服务一直可以瞬时响应、不出现内存泄漏问题…

内存问题终于解决了…之前吃了内存就不吐出来，还得设内存限制，都不好长期开着

太多了，这种能赚钱的很多都是早期没什么人做的时候直接 TTS+复制粘贴蹭算法推广，大批量起号恰烂钱。现在做的人多了，还能做起来的都得上特色人工配音、配符合剧情画面带人物的图、做多世界统一人设、账号矩阵二创互推之类的了。现在如果没基础流量和规范的工作流，真从零开始基本是做不起来的，我都已经看到好几个做不起来硬刷量的了，质量没质量，硬蹭算法又蹭不上。

@ch2 #22 有一说一，我认识的一些爬虫领域高水平从业者转方向（安全、架构、AI 、搜索引擎、算法、法务、自己开公司）的，核心原因都跟法律风险没太大关系，更多的还是觉得腻了或是累了，又或者是找到了新的兴趣点的。

而且觉得腻了和累了的这两种情况的差异还挺大，觉得腻了的是需要处理的东西基本没什么攻防对抗，大部分都可以套路化通杀，在框架早就搭好的情况下分分钟就能解决新需求或应对新改动，平时闲得都研究别的去了；觉得累了的是需要处理的东西几乎全都是各种高强度攻防对抗的，时不时就得加班研究对方又改了什么。

会因为法律风险驱使换工作或转方向的，更多是公司就是直接卖数据、自己不怎么加工数据的情况，这种本来就极其容易被找上门。但凡是基于采集到的数据做了处理，再作为产品对内外提供正经服务的，都没多大问题。

@Features #15 不清楚，我一般不用浏览器渲染，直接调接口较多，用浏览器渲染的时候都是量不大偷懒的情况，用哪个无所谓。

@jmss #9 cef （ https://bitbucket.org/chromiumembedded/cef/src/master/）可以理解成是一个在 chromium 核心的浏览器引擎部分（指页面渲染引擎+一些基础功能）的基础上做了一层封装的框架，而 webkit 是苹果的浏览器引擎。

说白了就是直接拿浏览器的核心部分用，而不是运行一个完整的浏览器，以提高性能和资源利用率。

另外，chrome 扩展和 selenium 虽然都是作为控制浏览器的工具，但由于运行环境的不同，也会存在各自的优劣势场景，实际还是要根据情况使用。比如 chrome 扩展可以直接提供给非技术人员使用，简单粗暴，心智负担低，但如果涉及到写数据库之类的操作就麻烦些，而用 selenium 这种外部程序控制浏览器的方式就不会有这个问题。

scrapy 是通用场景下的完整解决方案，把基本的处理流程规范、数据输出、分布式部署、后续运维管理等问题都解决了。
selenium 不属于爬虫框架，用在爬虫上只是作为一个控制浏览器的工具，本质上解决的只是请求和提取数据的逻辑部分。
chrome 扩展实际与 selenium 是一样的，也只是作为一个控制浏览器的工具。

所以很显然，scrapy 和另外两个完全不是同样的东西，前者可以在通用场景下做到简单配置就实现一个完整项目，后两者则需要自己开发除请求和提取数据以外的其他部分。