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。其实只是命令用错了对象。
- 区分三棵树：工作区（你看到的文件）、暂存区（
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）
