@mxT52CRuqR6o5 #8 因为目标不是只处理骚扰电话，是正常通话跟骚扰电话都要处理。
@zero47 #9 你永远无法预测有关部门啥时候会出手，你要知道就是工信部跟三大运营商的业务，都可能被广电一句话封杀。

不过为啥不能自由提供语音信箱，这个的原因我是真不知道。

@zero47 #4 小范围使用没人管，大范围使用，大概率手机的入网许可证要没了。

AI 俗称人工智障，你用它来接个人电话怕不是想被打死。

现在应该来追究一下，为什么中国的电信运营商，至今未提供稳定的语音信箱功能。

以及还要追究一下，为啥语音信箱功能，必须由运营商提供，手机不能用机器人程序自行提供。

微软就是故意这么设计的。你要知道约 10 年前的 Xbox One ，最初是要全程联网认证的，被怼了之后才改成 24 小时一认证。

@codehz #15 更新从来都不是问题。但随意更新 UI ，这可是 Chrome 独有，以及它的小弟 Edge 独有的。而随意变更 Web 规则，这可是作为 IE 2.0 的 Chrome 独有的。

这里不止浏览器，事实上你去翻下 IOS 、Windows 、Java 等的更新抵触原因，除了 Windows 这边独一份的「不想重启」外，大多不是不想更新，而是更新会带来副作用。IOS ，现在也应该加上 Android ，副作用是电池（并不一定是电池负优化，往往是原版对电池有优化，更新之后这个优化没了）。Windows ，主要是 Win 11 的更新副作用太多了，都懒得说了。Java 更新副作用就是，Java 9 开始不做向后兼容了，每次更新都要排坑。

@horizon #56 哦，原来是这个首先源分支上 「 rebase --no-ff 」，然后目标分支上 「 merge --ff-only 」，如果不能 rebase --no-ff 还不让做的 Github 专有的脑残方式。这个脑残方式是一定要禁止的，但请注意它并不是通常所说的 rebase merge 。

通常所说的 rebase merge ，是首先源分支上 「 rebase 」，然后目标分支上「 merge --no-ff 」，如果有冲突则可通过界面处理，这样的过程。Gitlab 、微软 Devops 、Gitea 等都支持这种方式，就 Github 出于提交签名的考虑，不支持这种方式。

自从 h.264 出来以后，gif 就是垃圾中的战斗机。

如果你只是需要一个本源浏览器，那么用开源的 Chromium ，不要用商业（免费）版的 Google Chrome 。如果你需要一个浏览器工具，换 Firefox （也是滚动更新，但很少动 UI ）。

不要想着禁用更新了，谷歌是全家桶一体更新的，你要仅使用 Chrome 还好说，你要是同时还用其他的，那么一禁全禁，任何一个有更新你得禁止也就失效了。

这就是经典的，名为「给你升官」，实为「免费干原本不该你干的事」

上面说了是本源原因，本来像说些治标的解决方法的，但想想我不是前端，哪能给解决方法。这个方法，还得前端自己搞。

只能作为旁观者，给一些经验。不管是被工期逼的，还是自己水平不行，后端能出这么烂的接口，说明整个项目都是烂的。这种情况下，前端即不要想着自己造轮子去处理，也不要想着逼后端去处理，直接每个接口都手撕代码，才是最能让自己不加班的处理方式。

前后端分离之后，两端是平等关系，不是上下依赖关系，接口定义要遵循的原则是：谁负责，谁主导；或者谁主导，谁负责。

理想情况下，业务模型（产品负责）、数据模型（后端负责）、UI 模型（前端负责）是打通之后一体设计的，那么前后端的接口开发方式是：前端定义，后端实现。（即时是一后对多前的情况下这种模式也可行，由后端负责将一套核心应用程序适配出来多套接口。）但现实情况往往是，（因为后端人数多、工资高）啥活都会压到后端，前后端接口的开发方式就编程了：后端定义，后端实现，前端被动使用。这时候，既然接口是由后端全权负责的，那么就是屎，你前端也得用。

@BeautifulSoap #33 第一，Github PR 合并选项就没有 rebase 。第二，rebase 的方向是从其他分支变更到个人分支，控制权完全在个人手上，你最多只能禁止 rebase 之后的 force push ，但禁止不了 rebase 。所以你说得是那个 rebase 。

surface pro i5 版本。

高性能就不要考虑了， 性能跟风扇是正相关的，不管你是啥架构。

摆脱别在让程序员去修电脑了。

你这个撑死了叫做资源安全部，跟信息技术、信息、技术，都没关系。

工厂组装馈线柜，实施是一次性的：请注意这个重点。

还要再加一个字：蠢。开源项目代码本身就是最大的文档，我倒要看看你怎么一边做开源项目——让别人贡献代码，一边文档收费。

一个人，滚。