技术栈少不等于系统简单。一个应用即便只有一个仓库也可能同时依赖多个外部服务、后台任务和隐式约定。深夜故障时需要理解的关系越多恢复就越难。我会用故障恢复来检验“极简”哪个组件停止会影响付款哪些任务能暂停备份恢复之后还要补什么。选型表里的语言数量只是表象。大公司的瓶颈不能照搬Anthropic在2026年10月13日发表、15日更新的源码管理文章讨论了其规模下源码管理与构建基础设施的瓶颈。它可以启发我们关注工具链承载能力不能推导一个独立项目也应该替换Git或自建同类系统。小团队更适合先列依赖确认每一项是否有明确负责人、恢复步骤和退出路径。引入组件前除了问能省多少开发时间也问故障时要增加多少学习成本。图里的辅助任务可以暂停不阻塞核心服务。若“发周报”故障会导致用户无法登录这通常值得重新检查依赖方向。用本地依赖图找出循环const assert require(node:assert/strict); function hasCycle(graph) { const visiting new Set(), done new Set(); function visit(node) { if (visiting.has(node)) return true; if (done.has(node)) return false; visiting.add(node); for (const next of graph[node] || []) if (visit(next)) return true; visiting.delete(node); done.add(node); return false; } return Object.keys(graph).some(visit); } assert.equal(hasCycle({ web: [api], api: [db], db: [] }), false); assert.equal(hasCycle({ web: [worker], worker: [web] }), true); assert.equal(hasCycle({ web: [web] }), true); console.log(dependencies: 3 assertions passed);保存为dependencies.cjs运行node dependencies.cjs。这只是小型有向图检查不自动扫描代码也不能证明无环系统一定可靠。真实依赖还包括配置、人工步骤和外部账号图要由维护者补全。给选择留下退出条件如果一个新服务只为一项非核心功能引入先考虑能否延迟、批处理或人工完成。必须引入时记录数据如何导出、故障如何降级、费用如何限制。删除一个依赖的成本也应进入最初的选择。本文没有测量真实系统故障率不声称极简选型把事故降到某个比例。本地代码只检查三种依赖图。更有用的目标是当系统出问题一个人能否在可接受时间里理解并恢复它。