提交前可以先跑一下 git diff --check，它会检查新增 diff 里的行尾空格和疑似空白错误。比等 CI 或代码评审时才发现省事。
环境：Git 2.25+，任意项目都能用。可以这样造个最小例子：
mkdir diff-check-demo && cd diff-check-demo
git init -q
git config user.email [email protected]
git config user.name dev
printf 'ok\n' > note.txt
git add note.txt && git commit -qm init
printf 'bad \n' >> note.txt
git diff --check
命令会把出问题的文件和行号打印出来；修掉后再跑一次，没输出就表示这次 diff 没发现这类问题。放到提交前钩子或 CI 里也挺轻量。
这个很适合塞进提交前钩子。补一个容易混淆的点：如果检查的是已经 git add 的内容，应该用 git diff --cached --check；不加 --cached 看的是工作区相对索引的 diff。这样钩子检查的范围才和实际要提交的内容一致。
CI 里也可以把检查范围直接对准变更基线，比如 git diff --check origin/main...HEAD，这样看的是这次分支相对主线的改动。它和提交钩子的 --cached 场景不一样，别把两个命令混着用；另外未跟踪文件不会被普通 git diff 检查到。
还有个小坑：git diff --check 的规则受 core.whitespace 影响，团队如果改过这个配置，CI 和本地结果可能不一致。可以在 CI 里显式打印 git config --show-origin --get core.whitespace，排查时会省不少时间。
再补一个边界：git diff --check 主要检查 diff 里的新增行，未跟踪文件和已经存在于基线里的脏内容不会被它单独揪出来。要把新文件也纳入 CI，通常先确保它已经进入比较范围；否则只靠这条命令，容易漏掉还没被 Git 跟踪的文件。