求知若渴，虚心若愚！
居安思危，积极进取！
前几天团队来了个新人，看到我们的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,后端可能分了几个服务,然后看到微服务很流行,就觉得前端也该"微"一下。这就是刻舟求剑了。
微前端带来的复杂度被严重低估
引入微前端后,你要面对的问题比想象中多得多:
前端圈对状态管理的执念，可能是过去十年最大的集体焦虑。从Flux到Redux，从MobX到Recoil，从Context API到Zustand，每隔一两年就会冒出一个"更简洁"的方案，然后大家又开始新一轮的重构和争论。
但我越来越怀疑一件事：我们在用前端的方式解决本不该存在的前端问题。
状态管理焦虑的根源
大部分前端开发者第一次接触Redux的时候，都会有类似的困惑：为什么一个简单的计数器需要写这么多代码？action、reducer、dispatch、connect，整整一套ceremony，就为了让组件拿到一个数字。
当时流行的解释是："这是为了可维护性。" 等项目大了你就懂了。
确实，等项目大了，我懂了。但我懂的不是Redux的好处，而是我们把太多不该放在前端的状态放在了前端。
举个真实场景：用户的投资组合数据。
前两天团队讨论新业务的技术方案,后端同学提议用 GraphQL,理由是"前端可以自己控制数据结构,不用频繁改接口"。我问了一句:"你们后端有多少人?"答:"3个人"。我说:"那别折腾了,RESTful 就够了"。
这不是第一次遇到这种情况。这些年做全栈,从后端写 API 到前端调 API 再到 BFF 层设计 API,见过太多技术选型上的执念。最常见的两个误区:一是觉得 RESTful 就是正统,必须符合所有规范;二是觉得 GraphQL 能解决前后端协作的所有问题。
事实上,这两个都不是银弹。
RESTful 的形式主义陷阱
大部分开发者第一次接触 API 设计,学的都是 RESTful 规范。GET 查询、POST 创建、PUT 更新、DELETE 删除,资源路径用名词不用动词,状态码要严格遵循 HTTP 标准。这些原则没错,但问题在于,很多人把它当成了教条。
前后端分离已经是前端圈的"政治正确"了。但最近几年，我观察到一个反常识的现象：不少团队在推进前后端分离几年后，又开始招聘全栈工程师，甚至把部分项目重新合并。
这不是技术倒退，而是对"分离成本"的重新认识。
前后端分离的三大隐形成本
大部分团队谈前后端分离时，强调的是"职责清晰"、"技术栈解耦"、"并行开发"。但很少有人提它的代价。
1. 沟通成本：从「对话」变成「会议」
以前一个功能，全栈工程师自己从前端写到数据库，遇到问题自己调试，半天搞定。
前后端分离后？先写需求文档，前后端对齐接口，联调发现参数不对，再开个会讨论，改完继续联调。原本半天的事，拉长成三天。
我不是说会议不重要，而是很多"会议"本质上是在弥补"认知鸿沟"——前端不知道后端为什么这么设计，后端不知道前端要什么。
金融业务尤其明显。理财产品的持仓逻辑，涉及到实时资产、历史收益、预期收益三种数据，前端需要合并展示。如果后端不理解前端的渲染逻辑，可能会返回三个接口；前端不理解后端的数据模型，可能会要求合并成一个接口但无法满足缓存策略。
这不是技术问题，是认知问题。
最近在一次技术评审会上，我听到一位工程师说："这段代码已经成为技术债务了，我们需要重构它。"当我追问为什么时，他回答："因为写得很烂，难以维护。"
这是一个典型的误解。技术债务从来不是代码写得好不好的问题，而是在特定时刻做出的理性决策。把技术债务等同于"烂代码"，就像把信用卡债务等同于"乱花钱"——你完全忽略了债务背后的战略选择。
一、重新定义技术债务
Ward Cunningham 在 1992 年提出"技术债务"这个概念时，他的本意是：为了更快交付价值，有意识地选择了一个不够完美但足够好的技术方案，代价是未来需要额外的工作来改进它。
注意三个关键词：
然而在实践中，我们常常把四种完全不同的东西都叫做"技术债务"：
> "工具本身从来不是问题的答案,理解问题才是。" —— 未署名的架构师
引言：一场永无止境的争论
在技术社区里,关于 API 设计的争论从未停止。REST 的支持者会告诉你:"遵循 RESTful 原则,你的 API 就会优雅、可扩展。" GraphQL 的拥趸则反驳:"单一端点、精确查询、类型安全,这才是现代 API 的未来。"
但如果我告诉你,这场争论本身就是一个错误的问题?
真正的问题不是"应该选择 REST 还是 GraphQL",而是我们为什么需要在两种范式之间做非此即彼的选择?更深层次的问题是:我们是否真正理解了 API 设计背后的本质问题?
REST 的谎言:资源导向的美丽陷阱
REST(Representational State Transfer)在 2000 年由 Roy Fielding 提出时,是一个革命性的概念。它将 Web 服务抽象为"资源"的集合,通过标准的 HTTP 方法(GET、POST、PUT、DELETE)进行操作。听起来很完美,对吧?
转一篇Notepadd++快捷键大全，转自：http://www.lianyue.org/2011/756/
Ctrl+C 复制
Ctrl+X 剪切
Ctrl+V 粘贴
Ctrl+Z 撤消
Ctrl+Y 恢复
Ctrl+A 全选
Ctrl+F 键查找对话框启动
Ctrl+H 查找/替换对话框
Ctrl+D 复制并粘贴当行