站点扩展术语：插件、钩子与模块的区别

站点扩展这个词常被混用，实际指代的东西差别很大。有人把一段附加功能叫插件，有人叫模块，也有人把挂载点叫钩子。术语不清，沟通成本和维护风险都会上升。下面按功能、适用场景、使用步骤和注意事项拆开讲。

一、三个核心术语的边界
插件通常指独立打包、可启用停用的功能单元，拥有自己的入口、配置页和生命周期，卸载后主程序仍能运行。钩子不是功能本身，而是主程序预留的挂载位置，扩展在特定时机插入自己的逻辑，本质是约定好的调用点。模块更偏向代码组织单位，强调职责划分与依赖关系，可以是插件内部的一部分，也可以是不带界面的纯逻辑层。判断方法很简单：能独立开关并对外提供完整功能的是插件；只负责在某个时机被调用的是钩子；只承担一段职责、不强调独立发布的是模块。三者可以嵌套，一个插件内部可以声明多个钩子，也可以拆成多个模块。

二、适用场景与选型思路
需要让使用者自由开关、按需加载的功能，适合做成插件；需要在不改动主程序的前提下介入流程，适合用钩子；需要复用逻辑、隔离复杂度，适合抽成模块。选型时先问三个问题：这段代码是否需要独立发布和停用？它是否必须在主程序的某个固定时机执行？它是否被多处复用？答案决定形态，而不是凭习惯命名。命名混乱的常见后果是：把业务逻辑写进钩子回调，导致调试困难；把该独立的功能塞进主程序模块，导致无法停用；把模块当插件发布，导致依赖缺失。

三、落地步骤
第一步盘点现有扩展点，列出可用的挂载时机与参数约定。第二步为每个功能写出启用条件、依赖项和停用后的回退行为。第三步按边界拆分：对外可开关的做成插件，介入流程的写成钩子回调，公共逻辑抽成模块。第四步建立命名规范，让名称直接体现形态与职责。第五步做停用测试：关闭扩展后主流程是否正常、数据是否残留、报错是否可控。第六步记录每个扩展点的调用顺序，避免多个扩展互相覆盖。

四、注意事项与自查清单
不要在钩子里做耗时操作，也不要在钩子里假设执行顺序；多个扩展挂同一时机时，顺序应由配置显式声明而非默认约定。停用不等于卸载，卸载前要确认数据清理策略。扩展之间的依赖要显式声明，避免隐式耦合。自查时逐条确认：形态命名是否一致、挂载点是否有文档、停用是否可回退、依赖是否声明、异常是否被隔离、升级是否影响既有配置。把这六项做成检查表，每次新增扩展前过一遍，能省下大量排查时间。

术语统一的价值在于降低协作摩擦。把插件、钩子、模块三者的边界写进团队约定，比反复口头解释更有效。遇到新说法时，先归入这三类之一，再讨论实现细节，讨论会顺畅很多。