Posts

状态机的核心是围绕状态，而不是围绕具体流程。当前状态、输入、转移状态，就是围绕着三要素设计的。它可以把一个超长流程、超多条件判断的流程，解耦为一个个独立的状态。 核心：围绕状态，而不是围绕具体流程 状态机的核心是围绕状态，而不是围绕具体流程。 当前状态、输入、转移状态，就是围绕着三要素设计的。 这个模式，可以把一个超长流程、超多条件判断的流程，解耦为一个个独立的状态。 将时序和条件判断，解耦为独立的状态，状态受输入/事件的影响，转移状态。 是一种分治，是一种将大的易变的脆弱流程，转换为一个个独立的、不易变的状态处理，也就是状态机。 状态机不是一种算法，而是一种通过"降维拆解"来控制复杂度的设计哲学。 它把混沌庞大的系统，解耦成了一个个简单、确定、封闭的小状态。 状态机不是循环，只是表现像循环。 我现在是 State A。如果来信号 X，我就变 State B；如果来信号 Y，我就变 State C。（循环只是状态切换过程中产生的一种表现形式） 状态机的核心四大要素 状态（State）：系统当前所处的情境（如"关门"、“开门”）； 输入（Input）：触发变化的外部信号（如"按下开门按钮"）； 转移（Transition）：从一个状态变到另一个状态的过程； 输出（Output）：系统在特定状态或转移时执行的动作（如"响铃"）。 状态机和循环流程的区别 状态机和循环流程看起来确实非常像，但它们在设计思想、状态控制权以及处理复杂度的能力上有本质的区别： 维度 普通循环流程（Loop / Flowchart） 状态机（State Machine） 控制中心 代码行/指令指针（PC）：按预设顺序一行行往下走 “状态"本身：当前处于什么状态，直接决定能响应什么信号 执行逻辑 主控驱动：A -> B -> C -> 再循环，路线基本固定 事件驱动：没有固定的下一步，完全看此时来了什么输入 分支处理 靠大量的 if-else 或 switch 嵌套，条件极易膨胀 状态独立隔离，只处理当前状态下合法的事件，拒绝非法输入 记忆能力 依赖全局变量或多层局部变量来标记"走到哪一步了” 状态本身就是记忆，当前处于哪个状态，就代表了过去发生的一切 状态机也是解耦 状态机解耦的是：“行为（做什么）“与"时序/条件判断（什么时候能做）”。 状态机通过把系统拆成"状态"和"事件”，实现了以下四个维度的彻底解耦： 1. 解耦：逻辑与当前上下文（消灭全局 Flag 泥潭） 传统代码（紧耦合）：为了记住系统"走到哪一步了"，你不得不定义一堆全局变量或布尔标志位（Flag）： if is_logged_in and not is_paying and is_verified and has_coupon: # 你必须在每一个逻辑里，手动判断这一大串 Flag 的组合 问题：变量越多，组合情况成指数级爆炸（2^n），你根本记不清 is_paying 为 True 时，has_coupon 能不能为 True。 ...

当流程跨越了多个服务，一旦中途某一步失败，如何把已经扭转的状态干净地恢复原状，是软件架构里最重的活。优秀的架构师会尽量避免物理回滚，把流程设计为只能向前。 核心：正向流程容易，逆向回滚才是灾难 当流程跨越了多个服务（分布式事务）或者多个本地对象时，一旦中途某一步失败，如何把已经扭转的状态、已经扣减的库存、已经划走的资金"干净地"恢复原状，是软件架构里最重的活。 一个设计大智慧：在真正的高并发高可用设计中，优秀的架构师会尽量避免"物理回滚"。 他们会把流程设计为"只能向前"。 比如扣款失败了，不是去把前面的流程撤销，而是生成一张"退款单"走新的正向流程。 用正向的业务去解决逆向的错误，这往往是把"面向对象"和"面向流程"结合得最好的艺术。 业务流失败的逆向控制（回滚） 正向流程容易，逆向清理（异常、回滚）才是分布式与复杂系统里的重活。 根据对"时序"和"状态"的处理方式不同，业界演进出了两类完全对立的治理哲学： 1. 命令式哲学：严格的因果追踪（有状态的设计） 传统的工作流（BPMN）或分布式事务（Saga / 2PC）认为"时间过程是可控的"。 编排式 Saga：由中央指挥官严格记录每一步的进度（Context），成功则前行，失败则按记忆逆向调用补偿接口； 两阶段提交 (2PC)：基础设施层强锁定，追求强一致性。 哲学本质：有状态的设计（Stateful）。 它极度依赖对时间轨迹的记忆。一旦回滚流程自身在网络闪断中崩溃，系统必须设计更复杂的"状态来套娃状态"，容易陷入脆弱的死锁。 2. 声明式哲学：消除流程的对账自愈（无状态的设计） 以 Kubernetes (K8s) 为代表的现代云原生架构，彻底推翻了"时间流水线"，转向了【声明式 API + 状态机 + 最终一致性】。 无回滚流：抛弃"先做 A、再做 B、失败了执行 C"的因果控制，直接定义对象的期望状态 (Desired State)； 控制循环 (Control Loop)：无数个健忘但勤奋的 Controller 每一秒都在比对"期望状态"与"实际状态"，计算出 Diff 并发起正向调节（Reconcile）。 哲学本质：无状态的设计（Stateless）。 控制器没有记忆，每一次触发都是纯函数的计算。它用无限重复的"空间对账"，消灭了"时间回滚"的痛苦。 声明式架构（K8s 风格）的边界与盲区 K8s 的"空间切分（容器化）+ 状态治理（etcd）+ 时间治理（控制循环）“在基础设施编排上近乎神作，但这套"无状态对账"并非万灵药。 声明式对账的天然盲区 当业务打破了"结果可定义、过程不重要、失败可重试、状态可覆盖"的假设时，必须坚决退回到命令式流程： 强时序/因果链业务（如银行转账）：必须具备完美的隔离性，无法容忍最终一致性走向一致期间的中间不稳定态（防止超卖或负资产）； 非幂等/不可逆操作（如发短信、物理扣费）：发生过就留下痕迹，无法通过"覆盖快照"来抹去，对账重试会导致严重的业务资损； 高频短暂任务（如 Serverless / 50ms 函数）：控制循环的对账代价（数百毫秒）远大于任务执行时间。 动作/流程的"对象化"误区 论点确认：转账、通知、审批、扣费，完全可以（且应该）被抽象为对象（如 DDD 中的交易单实体）； 关键分野：即使将它们抽象为了对象，它们也是"事务型对象”，而非 K8s 那样的"资源型对象"。 资源型对象 (Pod/Disk)：行为是"修剪"，多了可以删，少了可以建，允许短暂混乱； 事务型对象 (转账单/发票)：行为是"追加流水"，发生了就永远存在，必须用流水线一样严密的命令式流程（Saga）去呵护它的状态机跃迁。 四种回滚方案 1. 事务补偿模式（Saga Pattern） Saga 是分布式事务中最常用的"最终一致性"方案。它的核心思想是：不追求过程中的完美隔离，允许中间状态可见，但如果失败，就按原路反向执行"补偿操作"。 ...

流程是易变的、脆弱的，对象是稳定的、高内聚的。面向对象的流程是分治，将易变的流程拆分成多个稳定的对象，对象之间面向接口协作，复杂性拆分成局部复杂性。 现象 我们 iaas 很多代码都是面向过程，而架构上也有很多是面向过程，而没有面向对象。 比如创建主机，存储资源没有抽象，全都是在过程中各种条件判断来处理的。其实需要的是一个存储系统、存储对象。 创建备份也是一样，创建备份和存储备份耦合在一起，没有区分。 存储备份完全是面向过程，写了两个流程： rsync 上传到 snapshot； snapshot 之间复制副本。 其实创建备份和存储备份完全是独立的两个事务，而且是差别很大的两个事务。 很明显，存储应该是一个独立系统，是一个存储对象。 我们需要的是面向对象，过程应该是在对象内的。 核心：对象是骨架，流程是血肉 流程是易变的、脆弱的，编排流程； 对象是稳定的、高内聚的。 最终： 面向过程的流程，是一个大的、长的、前后依赖的、复杂性指数增加的判断组合； 面向对象的流程，是分治，将易变的、脆弱的，拆分成多个稳定的对象，对象之间面向接口协作，复杂性拆分成局部复杂性，在大流程里是一个线性复杂性，在对象内是常数复杂性。 相比面向过程的流程的指数复杂性，这是数学上可证明的面向对象的优势。 软件工程设计的目标就是 kiss，一切围绕控制复杂性设计。 宏观面向对象，微观面向流程 上层的业务流程确实是面向过程的，但它又不负责具体的业务规则，而是编排。 宏观架构上，要"面向对象"：划分好边界，把复杂的业务拆解成一个个职责明确、内聚的对象，以此来抗住需求的变更和系统的规模； 微观执行上，要"面向流程"：在 Service 层，清晰、直观地把这些对象串联成一条条业务流，满足用户的实际需求。 对象是骨架，流程是血肉。 面向过程 vs 面向对象 面向过程 优点：逻辑简单直接，符合人类"按步骤做事"的直觉；代码体积小、执行效率高；调试和上手成本低，适合小型程序； 缺点：可维护性差，需求变更时需修改大量相关函数，牵一发动全身；复用性低；扩展性差，难以应对复杂系统的需求迭代。 面向对象 优点：可维护性强，封装使对象内部变化不影响外部，模块化降低耦合；复用性高，继承和多态大幅减少重复代码；扩展性好，新增功能只需定义新类/方法，无需修改原有代码（开闭原则）；更贴合复杂问题的本质； 缺点：复杂度高，需设计类的结构、关系，上手门槛高；性能稍低；过度设计风险，简单问题可能被复杂化。 业务的悖论：用"空间对象"承载"时间流程" “业务的本质是流程（时间推进），但为什么现代软件工程推崇对象（空间治理）？” 这是软件设计中最迷人的核心矛盾。 我们通过 DDD（领域驱动设计）思想完成了这两者的空间与时间平衡： 宏观架构上（空间划分）——面向对象：划分出干净、内聚的领域模型（如用户、商品、订单）。这些对象是系统的"零件"，负责锁住状态与核心业务规则； 微观执行上（时间推进）——面向流程：在应用服务层，用直观的面向过程逻辑，将这些对象串联成一条条满足用户最终需求的"业务流"。 架构大智慧：对象是骨架（空间），流程是血肉（时间）。 好的代码，是用面向对象的画笔，画出面向过程的蓝图。 为什么业务是流，我们却要用对象？ 为了应对"变化"和"规模"。 如果一个业务流程永远不改，面向过程绝对是最高效的。但现实是，业务流程会无限膨胀和变化。 面向过程的灾难：假设一个"下单流程"，起初只有 3 步。随着业务发展，变成了 30 步，里面充斥着各种 if-else。最后这个流程长达几千行，没人敢改，因为改了第 5 步，可能会调断第 28 步的数据； 面向对象的解法：面向对象不是消灭流程，而是把流程中的"参与者（实体）“抽离出来，让它们自己负责自己的事情。下单流程不再是一条黑盒管道，而是变成了用户对象、商品对象、营销引擎对象、库存对象之间的交互。 用一个比喻来理解： 面向过程是"流水线工厂”：传送带上一条道走到黑，一旦产品要加个新功能，整条流水线可能都要停工重组； 面向对象是"现代企业组织"：划分为财务部、销售部、研发部。公司的业务依然是一个个流程，但流程是由各个部门通过协作完成的。如果财务流程变了，只需要财务部内部调整，销售部根本不需要知道。 小结 流程是易变的、脆弱的，对象是稳定的、高内聚的； 面向对象的流程是分治，复杂性拆分成局部复杂性； 面向过程的流程是指数复杂性，面向对象是线性复杂性； 宏观架构上要面向对象，微观执行上要面向流程； 对象是骨架，流程是血肉； 用面向对象的画笔，画出面向过程的蓝图。

决策流程这个场景，适合树而不是层。树是前后依赖的，层是前后不依赖的、每一层是通用的。规则引擎天生就是规则流，前后有依赖，所以写规则配置就是树的方式。 现象 树的方式对人是友好的，非常直观、快速理解。 如果我想知道我们是否支持 xxx + xxx 的组合，从左到右很快能得到答案。 如果是层，那么你需要知道每一层的逻辑，同时你还需要知道层与层之间的关联。 所以，决策流程这个场景，适合树，而不是层。 我们的场景 我们的场景是通过环境信息（cpu 架构、型号、qemu 版本等）设置 xml 配置。 这个场景推荐用树的方式，核心原因是架构（arm/x86）是"分支决定性条件"，后续逻辑完全依赖该分支，树结构能天然贴合独立流程、降低耦合。 逻辑贴合度高：你的需求本质是"架构分流 → 各自校验 qemu 版本 → 各自输出结果"，树结构的"分支独立"特性和这个流程完全匹配； 维护成本更低：后续若扩展（比如 arm 新增"内存≥4G"条件、x86 修改 qemu 版本要求为 > 5.0），树结构可直接在对应分支修改，不影响另一分支； 可读性更强：树结构能直观呈现"arm 线"和"x86 线"的完整流程，排查问题时可直接定位到对应分支。 还有关键一点，我们的场景每个流程线能复用的层比较少，比如 arm 直接就是 passthrough，后面流程都是针对 x86 设计的。 树 vs 层 如果是无依赖的过滤，反而适合写代码，比如 k8s apiserver 里的 webhook。 如果是决策流程，其实是规则流程，就适合规则引擎。 因为规则引擎天生的逻辑就是上一个规则结果传入下一个规则结果，它是前后有依赖的。 而无依赖的是独立的，代码更容易实现扩展性、精确性和复杂逻辑，且就算变化也是局部变化。 层结构更适合"条件无依赖、逐步缩小范围“的场景（比如先过滤系统类型，再过滤内存，最后过滤硬盘，每个条件不依赖前一个的具体结果）。 而你的场景中，qemu 层的判断逻辑（“满足版本后输出什么”）完全依赖前一层的架构结果，用层结构会导致： 同一层（qemu 层）需要嵌入"架构 arm"“架构 x86"的分支判断，违背"层是通用过滤"的设计初衷； 新增架构（比如 risc-v）时，需要修改所有后续层的逻辑，扩展性极差。 核心总结 树是前后依赖的； 层是前后不依赖的，每一层是通用的； 规则引擎的设计，天生就是为了规则流，前后就是有依赖的； 所以写规则配置的时候，就是树的方式，很难用层的方式； 层因为其通用，很可能有较大的复杂性，且还需要扩展性，一般适合用代码实现； 但是因为其通用和局部性，修改难度低，用代码反而比用规则引擎简单。 一切都是为了 kiss。 ...

mq 不仅是削峰填谷，也不仅是解耦服务，还有降低代码复杂性、增加稳定性的作用。中间件是一个稳定的、没有逻辑的、仅仅存储数据的。 现象 比如我们代码中安置逻辑里的 resource 的同步。 节点定时上报给 zoneleader，为了避免重复上报，节点自身又缓存了资源信息，每次上报前，先计算当前资源信息，然后和上一次缓存的资源信息对比，如果有差异，再汇报。 zoneleader 还会变。 上面两点，带来的复杂性： zoneleader 变了之后，节点得知道； 节点得区分 zoneleader 是否变化了，变了就直接上报资源信息； 节点不知道 zoneleader 用的资源信息是什么，说不定自己的缓存因为各种原因就不对呢； 处理异常情况能力弱。比如 zoneleader 因为个别原因更新失败，后续节点因为缓存的原因就不重试了。 这种方式虽然没有中心化的依赖问题，但是每个功能都需要处理上述类似的问题。 这是一种繁琐的、让代码复杂性大幅膨胀的方式，也是一种功能之间重复的、却不能统一处理的多余。 也是客户端和服务端相互紧密耦合的一种方式。 用中间件的方式 如果用中间件的方式： 客户端可以拉下来和当前资源对比； 服务端定期从中间件拉取资源即可； 中间件是一个稳定的、没有逻辑的、仅仅存储数据的。 所以： 客户端的逻辑只需要客户端处理，不变接口就不会影响服务端； 服务端也一样，自己处理逻辑，不用管客户端； 节点也不用关心 zoneleader 是不是变化了，它只想一个固定的中间件地址推送就行了； zoneleader 变化了，也不用想办法通知到其他节点，存储到中间件就行。 好处： 解耦； 不会相互影响了； 节点也知道当前使用的资源信息是什么样的，可以对比。 中间件依赖本身可以通过各种高可用方式保证其可用性，在现在已经不是什么主要矛盾或问题了。 小结 mq 不仅是削峰填谷，也不仅是解耦服务； 还有降低代码复杂性、增加稳定性的作用； 中间件是一个稳定的、没有逻辑的、仅仅存储数据的； 客户端和服务端通过中间件解耦，互不影响； 中间件依赖可以通过高可用方式保证可用性，不是主要矛盾。

check 有很多项，每个项都有修复。check 是一条线，修复是一条线。不要在 check 中发现某个项有问题就进行修复，而是要等 check 完再调用修复。 核心：check 和修复职责分离 check 有很多项，每个项都有修复。 那么： check 是一条线； 修复是一条线。 不要在 check 中，发现某个项有问题就进行修复，而是要等 check 完，再调用修复。 修复的里面比如也包含 check，但是这不能代替 check 流程。 因为有些情况，只需要 check，最典型的是告警和健康状态。 check 就得响应迅速，迅速告警。 里面掺杂了修复，有几个问题 健康状态不好管理：难道项目修复前是不健康，修复后改成健康，那下一个检查项呢？这样变来变去，很不稳定，上层没法用； 代码零散：就算在流程里更新健康状态，那得多零散，代码处理也不太好； 响应不及时：修复操作有的很耗时，影响 check 的效率。 检测和修复完全的职责分离 健康状态是检测修复。 那么修复的流程，即便修复完成，也不要管理健康状态。 下一次检测流程自然会更新健康状态。 小结 check 和修复要从大流程上就分开； check 是一条线，修复是一条线； 不要在 check 中发现某个项有问题就进行修复，要等 check 完再调用修复； check 就得响应迅速，迅速告警； 检测和修复完全的职责分离，修复完成也不要管理健康状态，下一次检测自然会更新。

底层逻辑尤其要保证单一，一个能力只提供一种方法。想要更多，通过上层组合、上层封装来实现。千万不要把所有需求都放到底层原子能力上。 核心：底层单一，上层组合 底层逻辑尤其要保证单一，一个能力只提供一种方法。 想要更多，那么通过上层组合、上层封装来实现。 千万不要把所有需求都放到底层原子能力上，虽然有些看起来好改，实际就是埋大坑。 符合设计原则、编程哲学是很重要和长久的。 来一个需求找一个好改的方式，这个评估维度是片面和短视的。 一个例子：网卡带宽 这个带宽控制是从精细化到模糊化管理。 从 iaas 的角度，这个管理方式是合理的，能适配多样化产品形态； 从产品的角度，需设计好统一的、标准化的控制方法。 nic 是网卡维度的控制； instance_extra 是云主机维度的控制； server.yaml 是全局控制。 看起来合理，实际没有人捋清楚，看代码看很久。每次梳理了就忘。 合理的方式应该是： 底层保持单一，容易理解； 云主机调整和全局的调整可以通过 api 来实现。 这样比较明确，以后也可以实现大会上说的"功能使用频率统计"。 批量、整体，这类操作，千万不要隐藏在配置或者底层的逻辑中，一定要以功能、api 的方式提供。 这样明确、可量化统计、可观测、可追溯。 小结 底层逻辑尤其要保证单一，一个能力只提供一种方法； 想要更多，通过上层组合、上层封装来实现； 千万不要把所有需求都放到底层原子能力上，那是埋大坑； 批量、整体操作，一定要以功能、api 的方式提供； 这样明确、可量化统计、可观测、可追溯。

Hook 侧重现有流程上运行时的局部修改，插件侧重模块化功能扩展，Middleware 是流程中可以扩展的横切面。三者核心目标都是不侵入主程序的前提下实现扩展。 Hook vs 插件 Hook 与插件是两种常见的扩展机制，它们在实现方式、应用场景和解决的问题上存在显著差异。 **Hook（钩子）**是一种通过拦截或修改现有流程的执行逻辑，插入自定义代码的机制。 插件是一种模块化的功能扩展机制，通过动态加载的独立模块向主程序注入新功能。 维度 Hook 插件 实现方式 拦截或替换现有流程（如函数调用、事件触发） 动态加载独立模块，通过 API 与主程序交互 侵入性 低（无需修改源码，直接拦截流程） 低（主程序无需依赖插件） 控制粒度 细粒度（可精确到单个函数或事件） 粗粒度（通常针对模块级功能） 动态性 运行时生效（如热补丁） 运行时加载/卸载（如插件管理器） 典型用途 行为拦截、动态修改、事件统一处理 功能扩展、模块化开发、多租户定制 hook 侧重现有流程上运行时的局部修改，插件侧重模块化、功能扩展、架构层的设计。 Middleware vs Hook Middleware（中间件）：是一种串联在核心流程上下游的组件，用于对核心操作的输入/输出进行预处理、后处理或增强。它通常形成一条"管道（Pipeline）"，请求/数据会按顺序经过多个中间件，最终到达核心逻辑，再沿原路返回。核心目标是解耦通用功能（如日志、认证、缓存）与核心业务逻辑。 Hook（钩子）：是在程序特定生命周期节点（如初始化后、销毁前、事件触发时）预留的"接口"，允许开发者注册自定义逻辑，在节点触发时自动执行。钩子不直接干预核心流程的输入/输出，而是"挂靠"在关键节点上响应事件。核心目标是提供扩展点，允许开发者在不修改核心代码的前提下，介入程序的生命周期或事件处理。 middleware 是流程中可以扩展横切面，可以扩展多个。hook 是某些固定的点上，留下 hook 口。 middleware 是流程上的扩展； hook 是功能点上的扩展，比如 delete 后，调用一个 hook 做一些其他资源清理或检查，但是这 delete 不一定会调用，不是流程必须的； middleware 就是主流程中的扩展。 Middleware vs 微内核 Middleware 是一种嵌入核心业务流程前后的组件，用于处理通用化、横切性的功能（即"横切关注点"）。它的核心作用是增强核心流程的能力，同时保持核心业务逻辑的简洁性。 微内核架构的核心是一个最小化的"内核"（仅包含系统最基础的能力，如模块管理、通信机制），所有业务功能通过插件（Plugin）动态扩展。内核不包含具体业务逻辑，仅负责插件的加载、卸载、通信和生命周期管理。 维度 Middleware 中间件 微内核架构 设计目标 处理"横切关注点"，增强核心流程的通用能力 支持功能动态扩展，实现系统模块化和解耦 与核心的关系 嵌入核心流程的执行链中，依赖核心流程存在 插件独立于内核，内核仅负责管理插件（不依赖插件） 调用方式 链式调用（前一个中间件处理后传递给下一个） 插件通过内核注册/调用，插件间通过内核间接通信 动态性 通常静态配置（启动时确定中间件组合），动态性弱 支持运行时动态加载/卸载插件，动态性强 功能定位 聚焦"流程增强"（如日志、认证、缓存） 聚焦"功能扩展"（如新增业务模块、工具） 典型示例 Gin 日志中间件、JWT 认证中间件 VS Code 插件系统、Linux 内核模块 关键区别总结 与核心流程的关系： ...

跟随主流技术非常重要，不要老用一些偏门的、古怪的技术凸显自己的别具一格。技术是手段，不是目的，所以越主流越好。 核心：跟随主流技术 跟随主流技术，非常重要。 不要老用一些偏门的、古怪的技术，凸显自己的别具一格。 比如，用 lxc 还是 docker。 别说两者底层原理都一样，用 lxc 自身可控性更好。生态和工具的适配完全是天和地的区别，这已经不是跨级别的问题，而是天壤之别。 再比如网络，主流都是用 ovs，所以别人智能网卡、dpu、新的一些设备、网络卸载等，适配的都是 ovs。 你自己搞一套，或者用小众的，别人不适配你啊。 还有国产化，都是靠着主流去适配的。 技术是手段，不是目的 技术是手段，不是目的。 所以，越主流越好。 主流代表着稳定、可靠、被大规模多场景验证过，同时有大量的解决方案和排查知识，也有大量的人才支撑。 手段不用在意创新，只需要稳定、可达、低成本。目的才需要考虑创新，创造价值差异。 小结 跟随主流技术非常重要； 不要老用偏门的、古怪的技术凸显自己的别具一格； 生态和工具的适配是天壤之别； 技术是手段，不是目的，越主流越好； 主流代表稳定、可靠、被大规模验证过，有大量解决方案和人才支撑。

什么是耦合，怎么判断有没有耦合？可以从结果反推：A 变化了，B 要不要跟着变化。如果跟着变，那就是耦合了；如果没有跟着变，或者变动很小，那就是松耦合。 核心：耦合的松紧关键在于变化 什么是耦合，怎么判断有没有耦合？ 可以从结果反推： A 变化了，B 要不要跟着变化； 如果跟着变，那就是耦合了； 如果没有跟着变，或者变动很小，那就是松耦合。 耦合的松紧关键在于变化。 小结 判断耦合可以从结果反推； A 变化了，B 跟着变，就是耦合； A 变化了，B 不变或变动很小，就是松耦合； 耦合的松紧关键在于变化。