Files
STM32F4-Base/docs/门禁说明/check-added-large-files.md
T
wandering1 6822726b2c docs(门禁说明): 手册 §2 收敛为通用机制与查号表,逐项详解归一到 23 篇
用户一句"现在门禁都在干什么,我一概不知"引出的收尾。原手册 §2 有 27 个逐钩子小节,只回答
"拦了什么、怎么配",回答不了"什么时候会骗我";docs/门禁说明/ 已把逐项详解(含"限制与盲区"
一节)建好,本笔做收敛:同一事实只留一处(docs/文档规范.md 的要求)。

**先搬后删**(否则收敛等于丢事实):旧 §2 里独有条目逐篇折回,共 18 处插入、15 篇受益。折回的
东西包括:六套主机单测的来历与用例规模(13/36/82/46/32/149 断言,含 nand-port 的"与旧算法
对照")与"改动公共骨架 unit_test_harness.py 会同时触发 16 个钩子";UI 页面**两层注册**(构建
注册 vs 框架注册:枚举 + s_defs[] 描述符表)与"豁免不整目录一刀切";lv-conf-sync 首次落地清掉
26 个 LVGL 9.3 不存在的选项、3 处重复定义、10 项隐式开关显式化,以及 ALLOW_DIFF 端专属白名单
与必须穿过 lv_conf_internal.h 里那层 KCONFIG 包裹;cubemx-survival 的 16 项清单、断言前先剥
C 注释(本仓注释刻意引用历史代码,不剥就恒定误报)、旧手册"自造标记区"建议与看门狗文档实测
教训之间的优先级;id-check 顺带收编 check_test_traceability.py、裸形同字母多义属**显式承认的
盲区**、--update-baseline 只许涨;layer-deps 的注入自证与报错时三条修法(注入回调 / 上层递数据
/ 才谈 ALLOW);coding-standard **nand_ftl.* 也在排除清单**(我先前那篇漏了);test-suite-switch
的剥注释判定与派生宏白名单;mem-budget 两类软提醒不拦、退出码 2 是解析失败不是通过;doc-links
的排除目录与状态词 ±40 字符距离;task-table 改栈三步;gitlint 报错样例;no-mojibake 的修复路径。

**顺带抓到旧文档两处错**(记进文档,不悄悄改):一是 check-added-large-files 的阈值旧手册写
"单个文件 > 1MB",按本机安装的钩子源码实测是 --maxkb 默认 **500**(500 KB)——已更正,并把
"本目录任何默认值都以实测或安装的钩子源码为准"写进 end-of-file-fixer 当反面教材;二是
**ui-golden 在旧手册里连小节都没有**,只活在配置注释里:除了"有基线不等于有门禁",这是另一种
失踪——有钩子、没文档。

手册 §2 改写为三节:迁移说明 / **旧编号 → 新文档 查号表**(历史引用靠它读,旧号按"冻结历史不
回改"保留)/ **跨钩子通用机制**:两阶段与换机必须重装 hooks 才带 commit-msg、stash 陷阱、
always: true 已废、改写型与只读型豁免不对称、增量拦截三段式且刻意没有 --write、没有 .map 是
"跳过"不是"通过"、改配置的验收是看目标钩子出现在输出里且不是 Skipped、新增门禁三步必须做
注入自证且"限制与盲区"不许留空,另有快速自查入口。手册 707 行 → 273 行。

引用**按内容**重指(只核编号存在与否不够,同号小节会被当本文自引用静默放过):编号规范、
scripts/README(顺带更正那里过时的 warn-only 说法,早已关闸为增量拦截)、RAM 使用分析与优化
方案、测试开发标准流程、lvgl-simulator skill、AGENTS 文档表(拆成"每门禁一篇详解"与"通用
机制"两行)、.pre-commit-config.yaml 头注释、docs/README.md 描述、手册自身 §5.5 与 §6 的两处
内部引用。另:表格里的裸节号会被 doc-links 判成本文自引用,查号表统一写成不带 § 的形态。

写说明过程又被自家门禁拦一次:gitlint 篇里引用报错样例时写了两个规则号字面量,被判形态不合规
→ 改成中文描述,没有往台账里塞 reason 解决。

验证:纯文档与注释改动,不动代码,Program Size 不变,故不跑 @build/@test;
check_doc_links --all --sections-strict **171 篇 0 问题**;id-check 增量拦截通过;
pre-commit run **RC=0 / 13 项 Passed**;28 个改动文件字节卫生 **0 异常**(无 BOM、无 CR、
无 U+FFFD、均 LF、无行尾空白)。
2026-10-23 11:44:21 +08:00

2.5 KiB
Raw Blame History

check-added-large-files — 别把大文件提进仓库

一句话:新增文件超过阈值(官方默认 500 KB)即拦。它防的是"手滑提交",不是体积门禁。

  • 配置:官方 pre-commit-hooks v5.0.0,未加参数 → 用官方默认阈值与默认行为。

1. 它在查什么

  • 新增(不是修改)文件的体积;超阈值即 FAIL。已入库大文件被修改不报——它只挡"新拉进来一个东西"。

  • 阈值的正确口径(本次核对更正):官方钩子的参数是 --maxkb,默认 500(即 500 KB)。 原手册这里写的是"单个文件 > 1MB",是错的(已按本机安装的钩子源码更正)。

2. 为什么要它

  • 本仓天然产出巨大的文件:MDK-ARM/**/*.map、.htm、.hex、build_log.txt、串口与自检日志、 截图。这些要么在 .gitignore,要么在生成文件豁免清单里;一旦有人手工 git add -f 一份 .map 或一轮台架日志,仓库就永久背上这个体积(删掉文件也不会变小,历史在对象库里)。

3. 触发面 / 看不见什么

  • 只看新增文件;不追历史里已有的大文件。
  • 不看目录总大小、不看提交次数、不看"未压缩但可压"的浪费。

4. 报错怎么读

check for added large files..............................................Failed
  docs/xxx.map (12.3 MB) is too large
  • 正确动作:别提交它(收进 .gitignore 或改放产物目录),而不是调高阈值。
  • 确实必须入库的二进制(子集字体生成物、golden 参考图)走体积可控的生成链,见 font-regen 与 ui-verify 的做法。

5. 好处

  • 挡住"最不可逆、最难补救"的那类错误(仓库膨胀只能重写历史来治)。

6. 限制与盲区

  1. 阈值是单个新文件的,不看总量、不看累积;
  2. 已入库的大文件永远绿(改它也不报);
  3. 很多小文件堆成巨型目录(例如 simulator/build/)完全无感——那类靠 .gitignore 挡;
  4. 顶层 exclude 与 .gitignore 的分工比这条门禁更根本(口径见 docs/代码规范/pre-commit使用说明.md)。

7. 豁免与基线 / 8. 改这个门禁本身

  • 无基线、无逐文件豁免开关;放宽只能给 args 加 --maxsize,而那会同时放宽所有新文件。

9. 变更记录

日期 变更
2026-10-23 首篇逐项文档(预防性门禁,未记录到本仓实际拦截案例)