解耦Decoupling
一句话
解耦是减少模块之间的直接依赖，让改动一处时不必连带改动一大片。
大白话
解耦像家里的电器都用标准插头：台灯坏了就换一盏台灯，冰箱坏了就换冰箱，不用把墙里的电线重新走一遍。
比喻的边界
插头规格是早就约定好的；代码里的“接口”要你自己设计和维护，拆得太碎、约定太多，反而更难改。
拿去就能用
开始做
我在做，和其他代码缠在一起，改它总会影响别处。帮我先列出它被哪些地方调用，再提出一个最小的拆分方案，我确认后再改。
还差：项目名称、想单独修改的部分，发给 AI 前记得换掉
出错了
我只改了商品列表的显示格式，结果订单页也坏了。帮我找出这两个页面共用了哪段代码、为什么会互相影响，先说明原因，不要顺手重构其他地方。
想做深
我的项目以后可能要把数据从本地文件换成数据库。帮我判断现在读写数据的代码是否集中在一处；如果没有，提出一个逐步收拢的方案，每一步都能单独运行验证。
别这样说 → 这样说
别这样说
代码太乱了，帮我解耦一下。
这样说
我想把支付方式换成另一家，但支付代码散在订单、购物车和通知三个文件里。帮我先列出所有调用支付的地方，提出一个把支付集中到一处的最小改法，我确认后再动。
差别：说出了具体想改什么、为什么难改，并要求先出方案。
容易误解：
误解把代码拆成更多文件、更多层，就是解耦。
其实是文件分开了，彼此却还在直接改对方的数据，依然是紧耦合；解耦看的是改一处要不要连带改别处，过早拆分只会增加来回跳转的成本。
展开专业理解
常用手段有关注点分离、封装和依赖稳定的接口：模块之间只通过约定好的函数或数据格式协作，只要对外约定不变，内部实现可以自由替换。好处是更容易单独测试和替换，代价是多一层约定要维护。新手项目里，先把明显会变的部分（支付、存储、第三方服务）收拢到一处就够了。
来源
- Microsoft Learn：架构原则 核对于 2026-09-26