北京
海外服务器访问图片CDN，连接慢、超时，或者下载到一半失败。错误日志写得很直白：IncompleteRead(49292 bytes read, 2611057 more expected)——读到四万多字节，剩下两百多万字节没了。
看到这种报错，第一反应通常是加重试、延长超时时间。潘锦在文章里记录了这个过程：这么做有一些缓解，但还是会出错。直到某天下午问题再次出现，他才意识到，重试和延长超时并没有解决本质问题，只是把问题往后推了推。
真正把方向拨正的，是暂时脱离业务、从基础事实重新查一遍：直接访问存储的外网地址是正常的，通过CDN就有问题；ping CDN域名，延时还能接受。剩下的可能只有回源。找云服务商定位日志，最终原因落在回源没有带源站地址，导致海外访问受限。至于为什么，云服务商没有做详细解释，只模糊提到跨境问题——因为在国内，之前的配置一直没有出过问题。
这个案例被拿来当作第一性原理的注脚：抛开经验、惯例和「理所当然」，回到最基础的事实和逻辑，重新推导解决方案。
文章把日常工作中容易偏离问题本质的思维陷阱归了三类。
- 经验主义陷阱：「上次遇到类似问题就是这么解决的。」技术在变、业务在变、用户在变，昨天的方案未必适合今天。文中举了一个电商订单系统超时的例子：后台人员凭经验判断是数据库性能问题，花大量时间优化SQL、加索引、分库分表，问题有所减轻但依然出现；从头分析才发现，真正的瓶颈是订单生成时要调用外部服务做各种校验和预处理，其中一个服务响应特别慢。
- 权威崇拜陷阱：「Google是这么做的，肯定没错。」大厂方案基于它自己的业务规模、技术栈、团队能力设计。文中提到一家创业公司，不到10人的团队、日活1万左右的产品，拆成了十几个服务，结果运维成本暴增、开发效率直线下降，最后不得不重新合并。
- 工具依赖陷阱：「用了最新的框架，一定能解决问题。」文中提到一个项目，前端框架从jQuery升级到Angular，又换成React，每次重构都说是为了提升开发效率和改善用户体验，但用户的核心诉求「页面加载太慢」从来没有被真正解决过。
文章给了两个拆解案例。一个是数据库连接池频繁爆满：连接池大小100，平均活跃连接数20到30，报错时连接数100，每个请求的数据库操作2到3次。既然平时只用20到30个连接，为什么会突然用满？监控显示每天下午3点左右连接数激增，深入代码发现有个定时任务在下午3点执行，并发处理大量数据，而任务的事务没有正确关闭，连接无法释放。修复事务管理的bug后问题彻底解决，连接池维持在50就够用。
另一个是永远优化不完的首页。静态资源上CDN、图片懒加载、接口合并、服务端缓存、数据库索引优化都做了，用户还是觉得慢。回到基础问题：用户说的「慢」到底是什么？用户访谈给出的答案是，他们说的不是首页加载慢，而是「找到想要的商品慢」——首页堆积了太多内容，用户需要不断滚动、寻找。
关于微服务与单体的争论，文章的处理方式是把约束条件先摆出来：团队规模是5个人还是50个人，业务复杂度是简单CRUD还是复杂业务逻辑，性能要求是日活千万还是几万几千，开发效率要快速迭代还是稳定运行。如果团队只有5个人、业务逻辑也不复杂，单体应用可能是最优选择：部署简单、调试方便、没有网络开销、事务处理简单。等单体真的成为瓶颈时再拆分，那时会更清楚哪些模块需要独立。
文章也划了适用边界。常规方法失效、面对全新问题、需要10倍改进而非10%优化、资源极度受限、团队存在重大分歧时，适合回到基础事实。有成熟解决方案的常规问题、时间紧急的情况、成本敏感的场景，则不必从零开始。作者的原话是：第一性原理也不是银弹，但它是一种强大的思维工具。
文中给出的操作框架分六步：定义问题、收集事实、分解结构、追溯原理、重构方案、迭代优化。第一步问的是问题的表象是什么、影响范围有多大、什么时候开始的；第二步要分清哪些是可以测量的数据、哪些是已经验证的事实、哪些还只是推测和假设。
至于「数据库索引可以提升查询性能」这类最佳实践，文章的态度是理解原理再判断适用性：索引用空间换时间，表很小时全表扫描可能更快，写入频繁时索引维护成本太高，查询模式复杂时单个索引覆盖不了。原理成立与否，得看场景。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
