git diff 查看工作区与暂存区差异，即已修改未暂存内容；git diff --cached 查看暂存区与最近提交差异，即已暂存未提交内容；git diff HEAD 查看工作区与最近提交全部差异，覆盖未暂存和已暂存改动。
git diff 查看工作区与暂存区的差异
直接运行 git diff 就能看到你改了但还没 git add 的内容。它对比的是工作区（你磁盘上的文件）和暂存区（index）之间的差异，也就是「还没准备提交的修改」。
常见错误是以为它能显示未跟踪文件（untracked files）——其实不会。新创建但没 git add 过的文件，默认不出现，除非加 -a 或单独用 git status -u 看哪些文件根本没被 Git 知道。
- 只看某个文件：
git diff path/to/file.js - 忽略空格变化（避免干扰）：
git diff -w - 用颜色高亮更清晰（多数终端默认开启，若失效可加
--color=always）
git diff --cached 查看暂存区与最近一次提交的差异
当你已经 git add 了一些改动，但还没 git commit，想确认「这次提交实际会包含什么」，就该用 git diff --cached（--staged 是等价写法）。它展示的是暂存区和 HEAD 的区别。
注意：如果暂存区为空（即没 add 任何东西），这条命令输出为空，不是报错，别误以为命令没生效。
- 检查即将提交的内容是否符合预期，尤其在多文件
add后容易漏看某一个 - 配合
git add -p分块暂存时，用git diff --cached可验证每一块是否真的进了暂存区 - Windows 上某些旧 Git 版本可能对换行符敏感，导致看似没改却显示大量
^M，可用git config core.autocrlf true缓解
git diff HEAD 一次性看全部未提交变更
git diff HEAD 是最直白的「所有未提交改动」快照：它跳过暂存区，直接比工作区和最近一次提交（HEAD）的全部差异。不管是已 add 还是没 add 的修改，全包括。
这命令适合快速审查整体改动范围，但信息量大，容易忽略细节。比如你 add 了 A 文件、改了 B 文件但没 add，git diff HEAD 会同时显示 A 和 B；而 git diff 只显示 B，git diff --cached 只显示 A——三者视角不同，不能互相替代。
- 想确认「从上次提交到现在，我到底动了哪些地方」，就用这个
- 如果改动太多，加
--stat先看修改分布：git diff HEAD --stat - 二进制文件（如图片、PDF）默认不显示内容差异，会提示
Binary files a/xx.png and b/xx.png differ，这是正常行为
为什么 git status 不够用？
git status 只告诉你「有修改」「有新文件」「已暂存」，但不告诉你改了哪几行。真正要定位问题、核对逻辑、避免误提交，必须靠 diff 系列命令。
一个典型疏漏场景：你 git add . 后顺手改了一个配置文件（比如 .env），但忘记 git add 它——git status 会标为「modified」，但你提交时它不会进去；而 git diff HEAD 能一眼揪出这个「游离修改」。
- 敏感文件（如含密钥的配置）常因这类疏漏被意外提交，
git diff HEAD是最后一道肉眼防线 - 团队协作中，别人基于你未提交的修改调试失败，往往是因为只看了
git status就以为「你已经提交了」 - IDE 内置的 Git 工具有时缓存滞后，终端敲一遍
git diff永远最可靠
