AngularJS 指令先解决模板复用，再谈更复杂的封装

第一次看 AngularJS 的指令示例时，很容易觉得它像一种“什么都能包起来”的能力。按钮、列表、弹层、表单，似乎都可以做成指令。这个想法没错，但如果刚入门就把所有逻辑都往指令里塞，通常很快会把自己绕进去。

先把指令当成可复用模板的容器

我现在更愿意从最朴素的场景理解指令：页面上有一段反复出现的结构，既有固定模板，又需要接一点简单配置，这时候指令就很合适。它让模板不再散落在多个页面里，也让复用不必依赖手工复制。

这种角度更容易把指令的边界看清楚。它首先是对视图结构的整理，其次才是行为封装。

指令里不要急着塞太多业务判断

早期写 AngularJS 指令时，一个常见问题是：只要页面上某块内容看起来能抽，就顺手把请求、状态、事件处理全写进去。结果就是指令越来越像一个小型应用，模板难读，作用域也变得难以追踪。

如果只是为了复用一段展示结构，保持接口简单会更稳。让外部控制数据输入，指令处理自己的模板和少量交互，后续维护会清楚很多。

模板复用做好了，团队收益会很直接

AngularJS 在 2014 年吸引人的地方之一，就是它开始让前端组件化有了更具体的落点。虽然当时大家还不一定会用“组件”这个词，但指令确实已经在解决类似的问题：统一视图片段、减少重复模板、降低页面间的复制粘贴。

对团队来说，这种收益比“语法很新”更实际。页面一多，统一一处模板比到处修细节省心得多。

小结

AngularJS 指令当然可以做复杂封装，但入门阶段更值得先抓住它最朴素的价值：把重复模板和局部视图结构收拢起来。先把这一步做好，再往更复杂的交互抽象推进，学习路径会稳很多。