Mason测评：按这套流程排掉六个坑
Mason测评不能只看能否生成文件，还要检查模板污染、覆盖风险、路径稳定性和团队复现。本文按一次完整验收流程逐步排坑：从安装环境、brick来源，到变量边界、钩子权限，再到升级和回滚。准备正式接入前，照着跑一遍更稳。
第一步：先验环境，别急着跑模板
第一个坑是CLI版本不一致。同一个brick在不同成员机器上出现差异时，先比较Dart与Mason版本，不要立刻改模板。团队应在文档或自动化环境中写明已验证版本。
第二个坑是PATH配置。安装成功不等于终端能找到命令；应同时验证 `mason --version`、项目目录权限和Git工作区状态。未提交的改动会让生成前后差异很难判断。
第二步：审brick来源与变量边界
第三个坑是直接运行陌生brick。模板不仅能写文件，还可能包含生成前后钩子。使用外部模板前，应检查 `brick.yaml`、`__brick__` 和hooks目录，确认没有意外命令或敏感操作。
第四个坑是变量输入不设边界。模块名若带空格、短横线或特殊字符，文件名和Dart类名可能不一致。测评时至少测试普通单词、下划线名称、空值和非法字符四类输入。
第三步：在隔离分支检查生成物
第五个坑是只看“生成成功”。正确做法是在临时分支运行，逐项核对新增与覆盖文件，再执行格式化、静态分析和测试。终端无报错，不代表import、包名和导出关系正确。
还要连续生成两个不同名称的模块，检查是否互相覆盖。若模板会修改公共导出文件，重复运行尤其危险；追加逻辑必须具备幂等性，否则同一行可能被写入多次。
第四步：升级、回滚后再下结论
第六个坑是模板不锁版本。公共brick一更新，旧项目可能生成新目录规范。正式使用时应记录来源和版本，升级前先在样例项目比较差异，不要直接影响所有仓库。
这轮Mason测评的合格标准很明确：新成员能复现、非法输入可控、重复执行不破坏文件、产物通过检查、模板可回滚。少一项，都不该急着推广到全团队。
常见问题
- Mason会覆盖现有文件吗？
- 是否产生冲突取决于生成路径和执行选项。不要依赖默认行为猜测，正式运行前使用干净分支，并检查目标目录是否已有同名文件。
- Mason的hooks安全吗？
- hooks本质上是可执行的Dart脚本，能力越强风险越高。外部brick必须先审查脚本内容，不要在含密钥或重要未提交文件的环境中盲目执行。
- 怎么测试一个Mason brick？
- 准备固定输入，在临时目录生成结果，再检查目录树、关键文本、格式化、静态分析和重复执行表现。模板升级时重复同一套测试。
- Mason适合直接用于生产项目吗？
- 可以，但应先锁定已验证版本、审查hooks、把brick纳入代码评审，并确保所有生成操作都能通过Git回滚。