git annotate 与 git blame 功能完全一致，仅为兼容旧脚本和 svn 用户的别名，输出格式略有差异但参数、逻辑和追溯能力完全相同。
git annotate 和 git blame 功能完全一致，只是命令名不同——它不是“更底层”或“更适合审计”的独立工具，而是为兼容其他版本控制系统（如 SVN）用户保留的别名。实际执行时，git annotate 会直接调用 git blame 的逻辑，输出格式略有差异，但底层行为、参数支持和追溯能力毫无区别。
git annotate 和 git blame 真有区别吗
没有实质区别。官方文档明确说明：git annotate 仅用于向后兼容和命名习惯迁移，输出默认更紧凑（比如不带时间戳），但所有关键参数（如 -L、-C、-M、--show-name）都通用。你用 git annotate -C -M -L 42,42 src/utils.js，等价于 git blame -C -M -L 42,42 src/utils.js。别被名字误导，以为 annotate 能绕过 blame 的限制。
为什么 git annotate 查不到刚改的代码
和 git blame 一样，它只看已提交的历史。未 git add 的改动、或已 add 但未 commit 的暂存区内容，都不会出现在结果里。
- 确认是否已提交：
git status看文件是否在 “nothing to commit” 状态 - 想包含暂存区修改：加
--cached参数，例如git annotate --cached src/utils.js - 纯工作区（unstaged）改动仍不可见——Git 没法把没记录的东西“ annotate ”出来
git annotate 跨文件移动后显示作者不对
默认不追踪重命名或拷贝，所以如果某行是从 old.ts 复制到 new.ts 的，git annotate 会把它当作“新写的”，作者显示为这次复制操作的提交者，而非原始作者。
- 必须显式启用检测：
git annotate -C -M src/new.ts（-C检测拷贝，-M检测重命名） - 两个
-C效果更好（-C -C），尤其对大段粘贴代码更敏感 - 注意性能代价：开启这些选项会使命令变慢，尤其在历史久、文件多的仓库中
代码审计时最容易忽略的关键点
真正难的不是运行命令，而是理解结果背后的 Git 模型约束：
-
git annotate只告诉你“最后一手修改者”，不是“原始作者”——如果某行是 merge 进来的，看到的是 merge 提交的 author，得配合git log -S "关键词" -- <file></file>定位引入点，再用git blame <hash>^ -- <file></file></hash>往上查 - IDE 内置的 annotate/blame 功能（如 VS Code + GitLens）常默认关闭
-C和-M，且缓存可能 stale；怀疑结果不准时，终端里跑一遍带全参数的命令才是唯一可信方式 - 中文作者名乱码，大概率是历史 commit 用了 GBK 提交，而当前终端用 UTF-8 解析——这时
git annotate -e加GIT_COMMITTER_NAME='中文名' git annotate临时绕过，但治标不治本
