坤霆@全栈技术研究室

每年Q1，技术团队都会经历一场庄严的仪式：写技术规划。

leader们关在小会议室里，对着白板画架构图，列痛点，排优先级，做资源估算。最后产出一个精美的PPT，把"技术债务治理""架构升级""效能提升"分门别类，附上里程碑和时间线。汇报的时候信心满满，老板点头通过，大家鼓掌散会。

然后呢？Q2还没结束，规划已经面目全非。Q3的时候，PPT里的那些项目，活着的大概只剩三分之一。到了Q4做复盘，大家心照不宣地跳过"规划完成率"这个话题，开始讨论明年的规划。

这个剧本，我见过太多次了。不是某一个团队的问题，几乎是一个行业现象。

规划是怎么死的

先说最常见的死法。

业务需求突然插队。 这个不用多解释，做过的都懂。理财业务突然要接一个新的资产类型，运营搞了个紧急活动，合规要求两周内整改——这些事情不会出现在你的规划PPT里，但它们会吃掉团队80%的产能。技术规划在业务需求面前，脆弱得像一张纸。

人力被抽调。 规划写的时候按10个人算的，Q1过完走了2个，Q2又借调1个去支援别的项目。你拿7个人去做10个人的规划，能完成就有鬼了。

每次聊性能优化，话题总是很快滑向具体的技术手段：懒加载、代码分割、图片压缩、Tree Shaking、虚拟列表……这些当然有用，但我想说一个可能让不少人不太舒服的判断——当你在做这些"优化"的时候，大概率已经晚了。 真正决定性能天花板的，不是你用了多少优化手段，而是系统架构在最初就给你画了多高的天花板。

性能问题从来不是前端单方面的问题。但很多团队把它当成了前端的问题，于是前端工程师就像一个装修工人，在毛坯房里拼命贴墙纸——墙纸再好看，承重墙没打好，房子一样不牢。

优化手段的天花板

先承认一个事实：常规的性能优化手段确实能解决一部分问题。一个从没做过任何优化的项目，加上代码分割和懒加载，首屏时间砍一半不稀奇。图片做个WebP转换、加个CDN，LCP直接降几百毫秒。这些是低垂的果实，摘了就是摘了，没人否认。

但问题是，这些优化有上限。你的首屏要从3秒优化到1.5秒，代码分割和懒加载就够了。但如果你要从1.5秒到800毫秒，甚至到500毫秒以内，单靠前端手段就力不从心了。因为剩余的耗时大头不在前端——它在网络请求、在服务端处理、在数据组装、在协议开销。

配置化平台这两年在金融和电商领域特别火。业务方想要灵活调整页面，需求排期又排不开，于是"配置化"三个字成了万能解药——做活动页？配置化。改文案？配置化。调整布局？配置化。好像只要搞一个配置平台，所有迭代效率的问题就烟消云散了。

但我想说一个可能得罪人的判断：大部分团队的配置平台，最终都变成了另一个更难维护的代码库。 只不过这个代码库没有版本控制，没有代码审查，调试靠肉眼，回滚靠运气。

配置化的承诺

先承认一个事实：配置化的出发点是对的。

在金融业务里，一个理财产品的详情页可能每周都要调整——改一个利率展示规则、加一个风险提示文案、换一个活动入口。这些需求的特点是：变频繁、逻辑简单、但等不及排期。 如果每次都走完整的需求-开发-测试-发布流程，前端团队光是接这些零碎需求就别干别的了。

配置化要解决的核心问题很清楚：把高频、低风险的变更从开发流程中剥离出来，让业务方自助完成。

这个思路本身没问题。问题出在执行上。

第一个陷阱：配置化的范围蔓延

几乎所有配置平台都经历了同样的演化路径。

有个现象我一直觉得很有意思：很多技术Leader当了Leader之后，比当个体贡献者时更忙了。

这不正常。

如果你的管理是有效的，你应该比以前更闲才对——因为你把事情分出去了，别人在做。但现实是，大部分Leader的日常是这样的：早上站会听进度，上午review代码，下午排需求优先级，晚上还要处理线上问题。忙得脚不沾地，但回头一看，团队离了你好像啥也干不了。

你以为这是"能者多劳"，其实这是一个信号：你根本没在管人，你还在管事。

管事和管人，不是同一件事的两种叫法

我见过不少刚做管理的朋友，聊起来都说"我在带团队"。但你仔细看他们的工作内容：拆任务、派活、盯进度、review产出、解决技术卡点……这些是管事还是在管人？

都是管事。

区别很简单：管事关注的是"事情有没有做好"，管人关注的是"人有没有成长"。前者是项目管理的范畴，后者才是团队管理的核心。

这个区分听起来像废话，但大部分技术Leader从来没认真想过这个问题。因为在工程师的世界观里，把事情做好就是一切。升Leader之后，自然也觉得"把团队的事情管好"就是管理。

上个月团队晋升答辩，有个同事没通过。技术能力很强，项目执行也不错，但评委说"影响力不够"。我问他怎么看，他说："我就是想写好代码，为什么非要搞那些虚的？"

我能理解他的委屈。在很多公司，晋升体系名义上是"能力导向"，实际上是另一套游戏规则。技术好不一定能升职，会讲故事、懂包装、有人脉的反而更容易上去。

但这真的是体系有问题吗？还是我们对晋升本身就有误解？

晋升评的不是技术能力，是组织价值

大部分工程师对晋升的理解是：我技术能力达标了，就应该升职。但公司的逻辑是：你对组织的贡献达到下一个级别了，才值得升职。

这两个标准完全不是一回事。

一个高级工程师可能写代码能力很强，但如果他只是完成分配的任务，没有带来超出预期的价值，那在组织眼里他就是"合格的高级工程师"，而不是"应该晋升的资深工程师"。

组织价值不是技术能力的简单加法，而是：在当前级别，你解决了多少原本不属于你职责范围内的问题。

上周一个团队成员找我聊天，提了个问题："既要做业务,又要做技术课题。但业务开发已经占满我的时间了,技术课题怎么办?"

我当时没有直接回答,而是反问了一句:"你觉得技术课题应该在什么时间做?"

他愣了一下,说:"当然是工作时间啊,不然呢?"

这个对话让我意识到,很多人对"技术课题"这件事的理解,从一开始就错了。

大部分人误解了技术课题的本质

先说结论:技术课题从来不是业务开发的平行任务,而是向上突破的选择题。

很多开发者把技术课题理解成"额外的工作任务",觉得应该和业务开发一样,在8小时工作时间内完成。这种理解有两个致命问题:

第一,技术课题不是分配来的,是争取来的。

在金融团队里,业务开发是职责范围内的工作,做不好要被考核。但技术课题不是——它更像是公司给你的一个额外机会:用时间和精力,换一个证明自己技术能力、拓展技术视野、提升团队影响力的机会。

既然是机会而非义务,凭什么要公司为你的成长买单?

第二,如果技术课题能在业务时间完成,说明它不够有价值。

大部分技术Leader在招人时都有个朴素的信念：能力越强越好，人越聪明越好。但在真实的团队管理中，我发现一个反直觉的现象：很多时候，团队出问题不是因为能力不足，而是因为认知跨度太大。

什么是认知跨度？就是团队成员在技术理解、业务认知、工作方式上的差距。这个差距小的时候是良性竞争，大了就是团队撕裂。

一个真实的场景

金融科技行业里有种很常见的情况：你招了一个大厂出来的P7，技术很强，对代码质量要求高，喜欢讨论架构。但你的团队主力是P5，关注的是怎么快速把需求做出来。

前两周还好，P7会主动做code review，提重构建议。一个月后矛盾就出来了：P7觉得"这代码没法维护，得重写"，P5觉得"功能都正常，改它干嘛"。三个月后，P7要么离职，要么就闭嘴了。

这不是谁对谁错的问题。这是认知跨度的问题。

认知跨度的三个维度

在技术团队里，认知跨度体现在三个地方：

技术深度的跨度。有人觉得"能跑就行"，有人觉得"必须优雅"。前者关注的是业务价值，后者关注的是技术品味。放在同一个项目里，一个想快速迭代，一个想精雕细琢，怎么配合？

做了这么多年技术，我发现一个挺有意思的现象：几乎每次技术方案评审，都会有人提出一个"理论上最优"的方案，但最后落地的，往往是那个"看起来不够优雅"的方案。

这不是偶然。背后有一套残酷的逻辑。

那个"完美方案"为什么总是死在会议室里

上周技术评审会，前端团队提出要引入微前端架构，理由很充分：模块解耦、独立部署、技术栈自由、团队自治。PPT做得精美，架构图画得漂亮，甚至连落地路线图都准备好了。

然后架构师问了一句："谁来维护基座？iframe降级方案谁负责？跨应用通信出问题谁排查？"

会议室安静了30秒。

最后的决定是：继续用现有的Monorepo + 模块化方案，虽然不够"先进"，但团队都熟悉，出问题知道怎么修。

这不是个例。我见过太多"技术上正确"的方案，死在各种现实问题上：

- 服务化改造，拆到一半发现团队根本撑不起这么多服务
- TypeScript全面迁移，三个月后发现一半团队还在用any
- GraphQL替代REST，半年后发现后端团队都不会写resolver
- Kubernetes上云，结果运维团队连基本的Pod调试都不会

有个场景在金融科技公司几乎每周都会上演:产品经理说"这个需求很简单,就是加个按钮",工程师听到的是"又要改架构"。

会议室里的氛围瞬间凝固。产品经理觉得技术团队在找借口,工程师觉得业务方根本不懂技术。双方都没说错,但都没说对。

这不是沟通技巧的问题,是认知框架的断层。

信息在组织边界丢失

我观察过一个现象:同一个需求,产品经理在需求评审会上讲五分钟,工程师回去讨论要两小时。

不是工程师理解力差,是信息在跨部门传递时发生了质变。

产品经理说"支持用户自定义理财目标",他脑子里是一个完整的业务场景:用户设定目标金额和期限,系统推荐合适产品,定期提醒达成进度。这个场景在产品原型里是完整的,在用户故事里是清晰的。

但工程师听到的是什么?

前端听到的是:新增表单、字段校验、状态管理、埋点上报。后端听到的是:数据库表设计、接口规范、权限校验、数据迁移。全栈工程师听到的更复杂:前后端联调、缓存策略、异常处理、监控告警。

同样五个字,解析出来的工作量相差十倍。

这就是组织边界的代价。产品经理思考的是"用户价值",工程师思考的是"技术实现"。两者的抽象层级不在同一个维度,信息当然会失真。

Monorepo 最近几年成了前端工程化的显学。Google、Meta、微软都在用，Turborepo、Nx 这些工具层出不穷，到处都在讲 Monorepo 的好处。但我观察下来，大部分团队引入 Monorepo 之后，要么是用成了"巨型仓库"，要么是过度拆分变成了"伪 Monorepo"。

真正的问题不是 Monorepo 本身，而是大家搞错了它的适用场景。

先说结论：Monorepo 不是银弹

很多团队看到 Google 用 Monorepo 管理几十亿行代码，就觉得自己也该用。但这里有个认知偏差：Google 的 Monorepo 是为了解决他们特有的问题——跨团队代码共享和依赖管理。

你的团队有这个问题吗？

大部分团队的实际情况是：
- 前端就 3-5 个人，管理的项目不超过 10 个
- 业务相对独立，跨项目共享的代码不多
- 没有复杂的内部依赖关系
- 团队协作流程还没稳定下来

这种情况下，Monorepo 带来的复杂度远大于收益。

做技术管理这些年,我发现一个有趣的现象:越是成功的技术Leader,越不愿意分享自己踩过的坑。大家都在讲"如何打造高效团队"、"OKR落地实践"、"技术人才培养体系",却很少有人聊那些让人坐立不安的尴尬时刻。

但恰恰是那些尴尬时刻,构成了技术管理的真实底色。

当你意识到自己是瓶颈

2019年,我负责的前端团队刚从5人扩到10人。团队扩张后的第三个月,我突然发现一个问题:所有人都在等我review代码。

不是他们不主动,而是我在无意识中给自己设置了一个隐形职责——"技术质量守门人"。每个PR我都要亲自看一遍,每个技术方案我都要参与讨论,每个难题组员都会第一时间找我。

表面上看这是负责任,实际上是灾难。

团队的吞吐量被我一个人的工作时间卡死了。更糟糕的是,我发现自己在培养"等待型工程师"——遇到问题不是先思考,而是先找Leader确认。这不是我想要的团队文化。

那段时间很煎熬。一方面我知道必须放手,另一方面又担心代码质量下滑。最让人尴尬的是,当我试图"授权"时,发现自己根本不知道该怎么做。

过去几年里,我习惯了"事必躬亲就能保证质量"的工作方式。现在要求我"不插手也能保证质量",完全是另一套技能。

每次看到 Dependabot 或 Renovate 提的 PR，我的第一反应不是"好，及时更新"，而是"又来了，这次会炸在哪"。

这不是危言耸听。见过太多次：一个看似无害的小版本更新，导致生产环境莫名其妙地挂掉；一个"修复安全漏洞"的补丁，带来了更严重的 breaking change；一个"只是升级 devDependencies"的操作，让 CI 流水线跑不起来。

行业里有个有意思的现象：所有人都在说"依赖要及时更新"，但实际操作中，大家都在拖延。不是因为懒，是因为怕。

这种恐惧是有道理的。

语义化版本的美丽谎言

Semantic Versioning（语义化版本）告诉我们：`major.minor.patch`三段式版本号清晰明了，patch 是 bug 修复，minor 是功能新增，major 才是破坏性变更。所以升级 patch 和 minor 是安全的，对吧？

对个屁。

去年金融业务的一次故障，就是因为某个依赖的 minor 版本更新。库的作者认为他只是"优化了内部实现"，所以只升了 minor。但这个优化改变了某些边界情况下的行为，恰好触发了我们业务代码里一个隐式依赖的逻辑。

写在前面

前几天和一个创业公司的 CTO 聊天，他说他们团队 5 个后端开发，已经拆了 12 个微服务。我问他为什么要拆，他说"为了未来的扩展性"。然后我问他现在的 DAU 是多少，他说"几千"。

这让我想起很多年前见过的一个场景：一个刚起步的业务，还在验证商业模式，技术团队已经开始讨论服务网格和分布式追踪了。最后业务没做起来，技术架构倒是挺先进的。

微服务这几年被捧得太高了。很多团队在根本不需要的时候就开始拆服务，结果把自己搞得焦头烂额。今天想聊聊这个话题，不是说微服务不好，而是大部分团队真的不需要它，至少不是现在。

微服务的真实成本

开发成本的指数级增长

很多人以为微服务只是把代码拆开而已。实际上，从单体到微服务，你需要解决的问题是指数级增长的：

服务间通信：HTTP 调用、gRPC、消息队列，你得选一个。然后你会发现，本来一个本地函数调用，现在变成了网络请求。网络不可靠，你得处理超时、重试、熔断。原本简单的代码，现在要考虑各种边界情况。

TypeScript这几年几乎成了前端的"标配"，不用TypeScript好像就落伍了。但我观察到一个现象：很多团队引入TypeScript后，开发效率反而降低了，尤其是启用了严格模式（`strict: true`）的项目。

这不是TypeScript本身的问题，而是大部分团队高估了自己的类型设计能力，低估了类型系统的复杂度。

类型系统的复杂度被严重低估

大部分人以为TypeScript就是"给变量加个类型"，但真正在大型项目中用TypeScript，你会发现类型编程几乎成了一门独立的学科。

看一个真实的例子，金融业务中的表单配置系统：

最近在和几个技术管理者交流时，发现他们都在规划或已经落地了BFF（Backend for Frontend）架构。问为什么要做BFF，得到的答案惊人地一致："解耦前后端"、"提升开发效率"、"这是最佳实践"。

但当我问："你们团队有多少后端开发？前端开发呢？"，答案通常是"后端6-8人，前端3-4人"。这让我意识到一个问题：大部分团队上BFF，可能不是因为真的需要，而是因为"别人都在用"。

我想聊聊这个话题，不是要否定BFF的价值，而是想说：很多团队高估了BFF的收益，低估了它的成本。

BFF真正解决的问题

先说清楚，BFF不是伪需求。它在特定场景下确实有价值：

场景一：多端适配。你的后端API是为Web设计的，现在要支持移动端、小程序、IoT设备。不同端的数据需求、交互逻辑差异很大，用一套API很难搞定。这时候BFF可以为每个端定制API，后端保持稳定。

场景二：聚合调用。前端一个页面需要调用5-6个后端服务，串行调用太慢，并行调用又要处理复杂的依赖关系。BFF可以在服务端聚合这些调用，减少前端的复杂度和网络开销。

最近看到一个问题："全栈工程师是不是什么都要会？"下面的回答分成了两派，一派说全栈就是要前端后端数据库运维都精通，另一派说全栈是个伪概念，啥都会等于啥都不精。

两边都有道理，但我觉得都错了重点。

做了很多年全栈，从后端写到前端，再到带团队做架构，我的观察是：大部分人误解了全栈工程师的核心价值。全栈不是让你成为技术全才，而是给你一个完整的视角去理解系统、做决策、解决问题。

追求全能是个陷阱，追求全局观才是正道。

全能是个伪命题

先说个真实场景。

在金融业务中，经常会遇到性能问题。前端说页面慢是因为接口慢，后端说接口慢是因为前端请求太多，DBA说数据库压力大是因为查询写得烂，运维说服务器资源不够要扩容。

这时候如果你是个"全能型"全栈，你会怎么做？去优化前端的渲染逻辑、重写后端的查询语句、调整数据库索引、然后去研究服务器配置？

听起来很厉害，但实际上这是在用战术上的勤奋掩盖战略上的懒惰。

真正的问题可能是：这个需求本身就不合理，或者整个架构设计有问题。

前几天团队来了个新人，看到我们的CR流程后很兴奋："你们的Code Review好规范啊，每个PR都要两个Approver才能合并。"我笑了笑没说话。

因为我知道，这套看起来"规范"的流程，实际上每天都在发生这样的事情：开发者提交一个几百行的PR，半天没人review；着急上线就去钉钉群里@几个人；被@的人打开看一眼，觉得代码没大问题就点了Approve；测试环境跑了一遍没报错，代码就合并了。

整个过程看起来很严谨，实际上谁也不知道这段代码到底干了什么。

大多数CR都是形式主义

我见过太多团队把Code Review当成一种"仪式感"——必须要有这个环节，但没人在乎它到底有没有效果。

最常见的场景是：PR提交后，reviewer们象征性地打开看一眼，扫过去没发现明显的bug或者格式问题，就点了Approve。至于这段代码的设计是否合理、是否有更好的实现方式、是否会给系统带来潜在风险，没人去深究。

为什么会这样？因为review代码比写代码累。

最近看到前端组有同学在讨论要不要把某个逻辑抽成公共工具函数。这个场景太熟悉了，几乎每个团队都在纠结类似的问题：到底什么该复用，什么不该复用？

我的观察是，大部分关于代码复用的讨论都建立在错误的前提上。不管是组件库、工具函数库，还是Copy-Paste，都不是真正的答案。真正的问题在于，我们对"复用"这个概念的理解就是错的。

组件库的幻觉

前端圈最大的迷思之一是：我们需要一个强大的组件库。

这个想法听起来很美好。把所有常用的UI组件抽象出来，封装成统一的库，然后各业务线直接调用。听起来既能保证一致性,又能提高效率。

但现实总是很打脸。

我见过太多这样的场景：某个业务需要一个带搜索功能的下拉选择器，组件库里有个Select组件。产品经理说要加个"最近搜索"功能，组件库维护者说这是业务定制需求，不该放在公共组件里。业务开发者只好在外面包一层。然后产品经理又说搜索结果要支持分组显示，再包一层。最后这个Select组件被包了三层，代码比从头写一个还要复杂。

问题出在哪？出在我们把"复用"等同于"抽象"。

最近看到团队在讨论页面首屏加载优化，有人提出要把某个 10KB 的图片压缩到 8KB，说能省 20% 的体积。我突然意识到，前端性能优化可能是我见过的最容易被过度执行、也最容易做错方向的技术工作。

不是说性能优化不重要，而是大部分人根本不知道自己在优化什么，也不知道这个优化到底值不值得。

性能优化的第一个迷思：技术指标不等于用户体验

打开任何一篇性能优化的文章，你都能看到一堆指标：LCP、FCP、TTI、FID、CLS。这些指标确实有价值，但问题是，你真的理解这些指标背后的含义吗？

我见过一个团队花了两周时间把 FCP 从 1.2 秒优化到 0.8 秒，但实际上首屏还是白屏，因为真正有意义的内容要等接口返回才能显示。用户看到的"快"，和监控平台上的数字，完全是两回事。

LCP 优化≠用户感知快。LCP 是"最大内容绘制"，但如果你的最大内容是一张无关紧要的背景图，优化它有什么意义？用户真正关心的是"我能不能看到商品价格"、"我能不能点击购买按钮"，而不是你的背景图加载了多快。

微前端这几年很火,但我见过太多团队在盲目引入后陷入困境。最常见的情况是:团队只有3-5个前端开发,维护着2-3个业务模块,却花了两个月时间接入qiankun,结果代码复杂度翻倍,问题却没解决几个。

这不是qiankun的问题,而是大部分团队根本不需要微前端。

微前端解决的是组织问题,不是技术问题

很多人把微前端当成技术架构来看,这是第一个误区。

微前端的核心价值在于让不同团队能够独立开发、独立部署自己的模块,而不是解决技术上的模块化或性能问题。如果你的团队只有一个前端组,那么引入微前端就像一个人住别墅——空间是有了,但打扫卫生的时间也翻倍了。

我在金融业务中见过一个典型案例:公司有理财、基金、保险三条业务线,分属三个独立团队,各团队技术栈不同(React、Vue、Angular都有),发布节奏也不一致。这种情况下,微前端是合理的选择,因为组织边界清晰,技术隔离是刚需。

但大部分团队的情况是:前端是一个Team,后端可能分了几个服务,然后看到微服务很流行,就觉得前端也该"微"一下。这就是刻舟求剑了。

微前端带来的复杂度被严重低估

引入微前端后,你要面对的问题比想象中多得多: