Post
网络摩擦与云端 build 优先
很多开发效率损耗并不来自编码本身，而是来自拉源码、下依赖和装工具这些被环境持续放大的外围摩擦。
有段时间外网很不稳定，build 代码、拉依赖、装工具，经常卡到怀疑人生。最后我被迫启用了一个很现实的办法：直接把改动推到仓库，交给 CircleCI 在云端构建。
这件事最让我有感触的，不是“云端构建真方便”，而是很多开发效率损耗，其实根本不发生在写代码的时候。
真正持续吞时间的，是这些外围动作：
- 拉源码
- 下载依赖
- 安装工具
- 搜索资料
- 获取镜像和构建环境
如果这些动作长期受网络摩擦影响，开发者的体验就会逐渐从“本地开发”退化成“先想办法绕开环境问题”。
所以我会觉得，很多时候我们高估了“工程师加班”的有效工作时长。表面上看大家都在努力写代码，实际上其中很大一部分时间，被各种环境摩擦一点点吃掉了。
而且这种摩擦并不只是网络带宽问题。
如果只是单纯带宽不足，理论上还可以通过 CDN、镜像加速、区域节点这些方式来逐步缓解。但一旦网络限制和制度限制叠在一起，问题就不再只是“慢”，而是很多全球通用的基础设施根本没法自然连通。
结果就是，一个本来应该统一的大互联网，被切成了多个体验完全不同的局部网络。开发者在不同区域面对的，已经不是同一个默认世界。
这件事最终会反向塑造工作流。
比如：
- 能放到云上跑的构建，就尽量放云上。
- 能通过
CI完成的下载和集成，就不要本地反复重试。 - 本地环境越来越像编辑器和提交器，真正重的构建逻辑迁到远端。
这未必是最理想的开发模式，但在高摩擦环境下，它往往是更现实的生存方式。
所以问题的关键已经不只是“某一次网络抖动”，而是当外围摩擦长期存在时，它会慢慢重写整个工程实践的默认形态。