可以把语音数据部分和传输部分解耦，不管啥格式的数据都可以在传输通道里走，这样你可以先上 MVP 方案用现成的编码格式，比如 mp3 ，等核心部分都搞定了，再看看是不是要替换语音编码。

除非你现在已经把 IM 核心功能都搞定了，就剩语音了。

@MrLonely #43 我的回复已经提到过了，如果互联网行业认为 PCDN 比 CDN 便宜，那么 CDN 的营收肯定是会下降的，所以不会是“CDN 该怎么卖就怎么卖”，而是会变成 CDN 不好卖了。
另外运营商自己搞 PCDN ，还按照 CDN 的价格，同时互联网行业完全可以自己搞 PCDN 的情况下，只有运营商的 PCDN 比自己的 PCDN 便宜、好用，才会倾向于采购运营商的 PCDN ，否则很可能还是各互联网行业自己搞。

问题的核心还是互联网行业想省钱，不管运营商怎么折腾，相同内容分发量用哪种方式更便宜，互联网行业就会选择哪种，也就是说如果某一天 CDN 变得比 PCDN 便宜，互联网行业会毫不犹豫抛弃 PCDN 方案，全面使用 CDN 。

但依然如我上一条回复所说，我认为当前对于运营商来说，CDN 比家宽利润更高（即便刨除 CDN 数据中心成本），运营商作为企业来讲没理由放弃高利润转方案，转而使用低利润方案。

我用 Node.js 写过 7 年后端，其中包括一些像交易系统之类的复杂业务，感觉还挺好用的。

前提是十分熟练掌握 JS 。因为 JS 是一个十分灵活的语言，所以对开发者要求很高，否则很容易写出存在缺陷或不容易 debug 的代码。

异步代码需要注意 catch 才能获得错误信息，不 catch 肯定不知道错误在哪；而且 Error 也需要准确构造和传递，否则也拿不到原始错误信息。

@kingterrors #7 async 和 await 是可以定位到准确位置的。

个人认为对于运营商来说，家宽业务利润低于 CDN 业务利润（利润=营收-成本）。PCDN 相当于将 CDN 的部分业务转移到了家宽业务下，如果网络服务供应总量不变，那么运营商在家宽业务的利润增长填不上 CDN 业务的利润下降，整体利润下降了。

我不是 CDN 市场从业人员，不了解细节情况，单纯从已知条件进行脑暴：

运营商卖 CDN 业务给互联网行业，希望 CDN 业务的利润最大化。
运营商卖家宽给家宽用户，希望家宽利润最大化。
原本这两个市场之间是隔离的，但 PCDN 的出现，打破了这种市场隔离:

因为国家在家宽用户网络服务上面有提速降费政策；
所以家宽市场利润被压缩。
所以相同内容分发量级下，家宽比 CDN 更便宜。

因为互联网行业在内容分发方面的目的是降低综合成本；
所以互联网行业的预期是利用家宽成本低于 CDN 成本，来通过 PCDN 降低内容分发成本（否则就不用 PCDN 了）；
所以互联网行业会减少采购 CDN 、增加采购 PCDN ；
所以①运营商 CDN 业务营收减少。

因为家宽用户可以靠 PCDN 回血；
所以家宽用户可能倾向于购买更大带宽，也可能不会；
所以②运营商家宽业务营收可能增多，也可能不变；

综合结论①和②，运营商整体利润可能减少。

如果带宽供应量有限，不足以完全满足 CDN 和家宽的需要，那么 CDN 应当是比家宽有更大利润的，所以运营商希望互联网行业按照 CDN 的定价来采购带宽，而不是按照家宽的价格来薅羊毛。
如果运营商自己做 PCDN ，相当于是放弃了 CDN 业务，也就是放弃了更高的利润。

以上是从纯网络服务方面来分析的，那么剩下就是 CDN 业务需要的额外计算、存储、机房设施的成本了，我是这样认为的：

运营商希望互利网企业采购 CDN 而不是 PCDN ，是因为 CDN 业务利润更高；
而 CDN 业务的利润是 CDN 业务的营收减去 CDN 业务的成本；
CDN 业务的成本包括 CDN 业务需要的除网络以外的计算、存储、机房设施等成本；
如果运营商将 CDN 业务迁移为 PCDN 业务，那么节省的除网络以外的计算、存储、机房设施等成，本无法填补失去的利润。

很多大公司搞计算机翻译搞了少说有二十几年了，现在才到了这种程度。

翻译讲究信达雅，如果机械翻译的话，你还要去理解机器翻译出来的东西，相当于还要再处理一个中间语言，更别说有的机翻结果跟原意差十万八千里甚至完全相反。

而且学英语的目的是用英语交流，用机械方式训练出来的英语，可能难以用于跟人类交流。

学英语其实无非就是语法、单词、思维；
单词没啥好办法就是背，顶多记一记词根和构词法能省很多功夫；
语法不学也可以，英语母语者也有没系统学过语法的，但他们是在一个纯英语生活环境里生活了很多年，非英语地区的人没有这个环境。学语法更多的目的更多是提升学习英语的效率，你不需要自己归纳整理以及形成习惯，语法都给你浓缩好了，直接套就行了；
最后最难的就是思维，比如中文里“辛苦了”在地道英语里怎么表达，我估计很多英语不错的人都会觉得困难，因为本质上还是中国人和欧美人的语言思维不一样。这个只能靠多听、阅读地道的英语内容，比如看美剧。

手机上装了个 12321 的 APP 。

接到推销电话后，在手机上加入黑名单，同时在 12321 的 APP 上登记举报。

不知道是否有效，反正现在接到推销电话不是很频繁，大概一个月一两次。

@simonlu9 #4 就是头饰的事都交给头饰服务来做，积分的事都交给积分服务来做。

积分兑换头饰的时候，积分服务只完成积分的核验、花费的部分，成功后通知头饰服务；头饰服务接到通知后专门有个给用户加头饰的过程。

展示用户头饰的时候，是直接调用头饰服务，来看用户拥有哪些头饰，已经目前正穿戴什么头饰。

单开饰品服务（或者头像服务）。

商城服务里面做 SKU 管理，用来管理多少积分兑换啥东西，需要对接饰品服务及其他用户可以兑换的实体所负责的服务。

商城服务只记录积分消费订单，不负责管理积分兑换的东西，用户兑换订单的时候通知饰品服务来给用户加饰品。

积分你可以单独作为一个微服务（比如积分钱包）被商城服务调用，也可以把积分服务扩展成积分商城服务，取决于你积分的主要使用场景是不是商城。

先抛开电学和机械方面的专业知识：
1. 有些家电是需要长期或同时使用的，换来换去麻烦；
2. 很多时候电机只占小部分空间，比如吸尘器并不是电机+吸管，起关键作用的还有风道和尘盒（而且占体积不小），至少你要抽清洁水的时候肯定不能用吸过尘的风道；
3. 模块化的东西好修，但相对容易坏，反复拆装一些部件会疲劳；
4. 模块化的产品通常比一体化的贵，比如 1 个设备可以具备 5 个设备的功能，但它大概率比买 3 个设备要贵，而且大多人只用到其中 2 个功能……

当然我说的都是我所观察到的普遍情况，可能会存在例外情况。

@anonydmer #1 哈哈哈，看到这个回复绷不住地笑了……

@HarrisonLee 有时候业务上的关注是有侧重点的，而一些人希望先看到最关注的东西；比如业务上关注的条件在代码里只能使用“!condition”这种方式来表达，如果强行掰成“condition”并交换 if 和 else 块，计算机倒是无所谓，但是人顺着业务需求来看代码就也需要在大脑里进行一下转换。我个人倾向于业务需求文档咋写，代码就怎么写，让读代码尽可能少些逻辑转换，提高效率、降低 bug 概率。
当然，也不是说这种是唯一用来提高可读性的方式，也可以用注释，或者单独声明一个反义变量，这个就是看个人或团队的代码风格了。
最后只能说这种写法不是禁忌，也不一定任何时候都没有好处，具体还是看情景，看是不是确实没必要。

就是管理问题。

1. 公司没有响应时间的制度要求，比如什么时候用即时通信讯工具、电话、邮件，各自的响应时间要求是什么；
2. 协作有没有接口人制度，接口人是否粒度够细，是否有引导转接机制，接口人是否全面负责内部协调；
3. 文档是否是 QA 的一部分，是否 QA 负责人会对文档进行审计，是否有高效自动生成文档的方案；
4. 是否有需求评审周期，是否有需求处置流程，需求是否分优先级；
5. 中台工作内容范围是否有明确规定，是否有针对争议需求进行裁决的流程；
6. 上线时间方面的保障是否体现在绩效中。

任何跟社会学沾边的东西，都只能人来解决，技术是解决不了的。

语言是交流的工具，最终目的是准确表达和接收意思；括号和倒装都是语言提供的特性，怎么用、什么时候用，全看个人；语言上也不会认为这些特性就是禁忌；只要能高效、准确传达意思，有必要的话甚至可以无视语法规则。

而且随着文化发展，词语的含义、读音、用字也在发生变化，语言特性也在增多，比如现在也流行用拼音首字母缩写（如“yyds”），以及一些代音词（如“集美”）。

“择其善者而从之，其不善则而改之”，你可以有更高的语文技能追求，可以严于律己，但对他人过高要求就会显得自己刻薄、难以交流。

谷歌翻译就是网友贡献的翻译样本，也就是说不光有 typo ，甚至可以投毒的（而且发生过），可以在 V 站搜一下“谷歌翻译”。

下一步自己组装客制化键盘 😏

我目前在用 Ultimate Hacking Keyboard ，很多部件可以自己替换，固件完全开源，估计可以折腾好久了。

分区只是一种手段，目的是为了满足需求，只有当你了解了你的需求，并了解了如何规划分区可以满足你的需求，你就知道要不要分区了。

每个人的需求可能有差异，所以最终使用的手段可能有差异。

对于我来说，有这么几个情况：
1. 重装系统频率低，我从 2015 年开始用 Win10 ，到如今升级了 Win11 ，没有重装过系统，不像以前用 XP 的时候，系统用一段时间就卡，就得重装。
2. 我的大部分应用程序都强制使用%appdata%作为用户数据存储的路径（比如游戏存档），而且还涉及到多种程序依赖同一个路径的情况，即便真的要重装系统，也是要手动备份出来的。
3. 一部分应用程序，尤其是硬件驱动极其配套软件，是只能安装在系统路径下，没有选择的余地，即便要重装系统，还是要重装。
4. 有些应用程序即便装到了其他分区，因为注册表、依赖库等还是在系统目录下，即便只格式化了系统盘，重装后依然无法正常工作，还是要重装应用程序。
5. 偶尔会有大量占用磁盘空间的需求，比如把大量文件下载到本地进行处理，处理完得到结果再删除，分区将会导致磁盘空间的利用不够灵活，到时候还要去折腾无损分区调整。
6. 系统使用空间的情况是动态变化的，比如更新较多较大的情况，以及产生大量临时文件的情况，都需要有很大的缓冲空间，如果系统分区空间不够，同样要折腾无损分区调整。

有人可能会说，我完全可以使用各种奇淫技巧来解决这些问题，但我想说，对于我个人来说，使用奇淫技巧可能要比不用更麻烦，重装系统备份文件对我来说并不是个难事，直接用户目录一锅端就可以了，软件需要用啥再装，还能顺便摆脱一些装了但长年不用的软件。

注意，以上说的都是我个人的需求情况，其他人可能跟我不一样，以我自身对 Windows 的掌握水平，我选择不分区。
这种事情没有完美方案，就是做取舍，你想得到什么，你愿意失去什么。

尽量把主观情绪抛掉，把找工作当成上学时候的考试，复习、考试、订正、复习、再考试。

好几年没有优惠了，以前 10 月 24 号还有买一送一。

你可以试着给他们销售或者客服发个邮件问一下有没有优惠，比如第一年开始就享受续费优惠价。

临时用就是 Python 起个 http 模块，一条指令的事；
长期用装个 Ngingx ，配置个 root 开个 autoindex 就完事了。

系统架构上没有银弹，一切都应该从需求出发，虽然我做微服务基本上也是一个服务一个数据库，但从来不是认为每个微服务就应该单独配数据库，而是经过权衡后恰好这样做符合业务和技术上的需要，换言之，也存在一些微服务场景可以共用数据库的，甚至一个服务可以有多个、多种数据库。