git diff --cached 对比暂存区与HEAD的差异，即已add但未commit的更改；默认不显示新文件内容，等价于git diff --staged，用于提交前确认变更。
git diff --cached 看的是什么
它对比的是暂存区（index）和最新提交（HEAD）的差异，也就是你 git add 进去、但还没 git commit 的那些改动。不是工作区和暂存区的差异，也不是工作区和 HEAD 的差异——这点最容易搞混。
常见错误现象：git diff --cached 没输出，但你明明刚 git add file.txt 了。原因通常是：文件在 HEAD 和暂存区完全一致（比如你 add 的是未修改过的文件，或刚 commit 完还没改），或者你误用了 git diff（它默认比工作区 vs 暂存区）。
- 使用场景：写完代码
git add .后，想确认“这次提交到底会包含哪些变更”，再点确认 - 等价命令：
git diff --staged（--cached是旧名，两者完全一样） - 如果只关心某个文件，加路径：
git diff --cached path/to/file.js
为什么 git diff 不显示暂存区变化
git diff 默认对比工作区和暂存区，不涉及 HEAD。所以即使你 add 了修改，只要没再改工作区，git diff 就是空的——它压根不查暂存区和上一次提交的关系。
容易踩的坑：git status 显示 “Changes to be committed”，但 git diff 没反应，于是以为没成功 add。其实只是命令用错了对象。
监控一个或多个 GitCode 仓库的 PR，通过 OpenClaw Gateway 自动执行 AI 审查，发布 PR 评论，并发送钉钉和企业微信通知。
- 区分三棵树：工作区（你看到的文件）、暂存区（
git add后暂存的快照）、HEAD（上一次提交） -
git diff→ 工作区 vs 暂存区 -
git diff --cached→ 暂存区 vs HEAD -
git diff HEAD→ 工作区 vs HEAD（全量差异）
diff --cached 输出里看不到新文件？
对，git diff --cached 默认不显示未跟踪的新文件（untracked files），哪怕你 git add newfile.py 了，首次 add 的全新文件在 diff 中只以“new file”标记出现，不会显示具体行内容——Git 认为它没有“上一版本”可比。
性能影响：对大仓库，--cached 只读取 index 和 HEAD 的树对象，速度比 git diff HEAD 快不少，尤其当工作区有大量未 add 的临时文件时。
- 想看新文件的完整内容，用：
git show :path/to/newfile.py（冒号开头表示从暂存区读） - 想强制显示新文件的 diff（含内容），加
-p参数：git diff --cached -p，但注意：首次添加的文件仍只标“new file”，内容需配合git show - Windows 用户注意：行尾换行符（CRLF/LF）可能被 Git 自动转换，导致
--cached出现看似无关的 diff，检查core.autocrlf设置
用 git diff --cached 做提交前最后验证
这是最接近“真实提交内容”的视图，也是 CI/CD 流程里常模拟的阶段。但它不等于最终提交结果——因为你在 git commit 前还可能 git add 更多、或 git reset 掉部分暂存项。
容易被忽略的地方：如果用了 git commit -a，它会自动 add 所有已跟踪文件的修改，绕过暂存区流程，此时 --cached 就不能代表实际提交内容了。这种情况下，得用 git diff HEAD 预览。
- 推荐组合：先
git add -p交互式暂存，再git diff --cached确认，最后git commit - 别依赖 IDE 内置的“提交预览”，它不一定走 index 路径，可能漏掉
git add -u或子模块变更 - CI 脚本里慎用
--cached判断变更范围，因为 CI 环境通常不带暂存区（除非显式git checkout+git add）
