权限混淆本质是边界不清导致误改、绕审、泄密，需从代码结构、工具链、CI流程三层面联动管控：按模块职责定义编译范围，用CODEOWNERS+工具链拦截越权操作，隔离构建产物并校验环境，建立权限日志与追溯机制。
权限混淆在复杂 Monorepo 中，本质是“谁该改什么、谁不该看什么”没划清边界，导致误改共享模块、绕过审查、或敏感配置被随意读写。厘清编译权限不是加个 Git 钩子就完事，而是要从代码结构、工具链、CI 流程三层面联动控制。
按模块职责定义编译范围
编译权限必须绑定模块的“可变性”和“影响域”，而非简单按目录路径放行：
- 只读模块（如 shared/utils、shared/types）：禁止任何直接修改，CI 中禁止触发其构建；仅允许通过 PR + CODEOWNERS 自动指派审核人后，经严格评审才可变更
- 业务模块（如 apps/web、apps/mobile）：对应团队拥有完整编译权，但构建产物仅限本应用上下文；若引用 shared 模块，需显式声明版本快照（如 pnpm link 或 workspace:^），避免隐式依赖污染
- 发布模块（如 packages/ui、packages/api-client）：编译权限与语义化版本挂钩——只有 tag 推送或 release 分支合并才触发正式构建；日常开发分支仅允许本地构建，不上传 artifact
用 CODEOWNERS + 工具链做细粒度拦截
Git 的 CODEOWNERS 是第一道防线，但需配合构建工具才能真正生效：
- 在 .github/CODEOWNERS 中按路径指定 owner，例如：
/packages/utils/ @utils-team、/apps/finance/ @finance-team - CI 脚本中调用
turbo run build --filter=... --no-cache前，先解析本次 commit 修改路径，比对 CODEOWNERS 规则；若修改了非所属模块，直接失败并提示“越权修改 shared/config，请联系 @infra-team” - pnpm workspace 配合
prepublishOnly钩子，在打包前校验当前包是否在允许发布的 scope 内（如 finance 目录下不允许发布 ui 组件）
构建产物隔离与环境感知编译
编译权限混乱常源于“同一份源码打出多套产物”，结果一个模块被错误注入到不该出现的环境里：
- 每个模块的
tsconfig.json显式声明"composite": true和"incremental": true，强制启用增量编译；同时通过"references"明确依赖链，避免跨模块无感知编译 - CI 中区分
build:web、build:rn、build:ssr等脚本，各脚本只加载对应平台的tsconfig.app.json，且构建命令强制传入--filter参数限定作用域（如turbo run build:web --filter=apps/web...） - 敏感模块（如 auth-core、payment-gateway）启用编译时环境变量校验，未设置
NODE_ENV=prod或缺失SECRET_KEY时直接中断，防止误打调试包
权限日志与事后追溯机制
光靠预防不够，关键是要让每次编译行为可查、可溯、可问责：
- 所有 CI 构建任务输出中嵌入
git show -s --format="%h %an %ae %s" HEAD，记录提交者、邮箱、摘要；同时打印本次构建实际生效的--filter列表 - 将构建日志同步至内部审计系统，按模块路径建立索引；当某次线上故障关联到
packages/shared，可秒级查出最近 72 小时内所有对该路径的编译触发记录及责任人 - 每月自动生成“越权构建报告”，统计非 owner 提交却触发某模块构建的次数，用于优化 CODEOWNERS 覆盖率和团队协作规范
