git status 输出中“Changes to be committed”下方列出的文件即为已暂存文件；该行是唯一可靠标识，其后提示“(use "git restore --staged <file>" to unstage)”进一步确认暂存状态。
git status 怎么一眼看出哪些文件已暂存
直接运行 git status，输出里只要看到 “Changes to be committed” 这一行，它下面列出的所有文件就是当前已暂存的文件。这一行是唯一可靠标识，别被 “Changes not staged” 或 “Untracked files” 干扰。
常见错误现象：改完文件后没 git add，就急着看 git status，结果只看到 “modified: xxx.js”，误以为它已暂存——其实它还在工作区，属于未暂存状态。
实用技巧：
- 加
-s参数（git status -s）能压缩输出，已暂存文件第二列显示M（modified）、A（added）、D（deleted），第一列为空；未暂存但已修改的，第一列是M，第二列为空 - 如果仓库很大、文件极多，加
--untracked-files=no可屏蔽未跟踪文件，聚焦已暂存/已修改项 - 注意终端输出中那句提示：
(use "git restore --staged <file>" to unstage)</file>—— 出现这句，说明上面的文件确实已在暂存区
git diff --cached 和 git diff --staged 有区别吗
没有区别。git diff --cached 和 git diff --staged 是完全等价的两个命令，都表示「对比暂存区（index）和上一次提交（HEAD）」，输出的是你即将提交的内容。
容易踩的坑：
- 误用
git diff（不带参数）：它对比的是工作区 vs 暂存区，不是你想看的“已暂存内容”，容易混淆 - 执行时没指定文件却期望看到单个文件差异：直接加路径，例如
git diff --cached src/main.py - 输出为空？说明暂存区跟上次提交完全一致——要么你还没
git add，要么刚git commit完，暂存区是空的
VSCode 里点“STAGED CHANGES”却看不到高亮差异
本质是 VSCode 没对上对比源。它默认把左侧当暂存区、右侧当工作区，但前提是：你必须先保存文件（Ctrl+S / Cmd+S），且点击的是“STAGED CHANGES”区域里的文件名，不是“CHANGES”区域。
典型失败场景：
- 编辑器里改了代码但没保存，直接点“STAGED CHANGES”下的文件 → 右侧空白或显示全量内容，无 +/- 标记
- 点错了区域：在“CHANGES”（未暂存）列表里右键 Open Changes → 实际触发的是工作区 vs HEAD，不是工作区 vs 暂存区
- 左下角没显示分支名（如
main）→ 当前打开的不是 Git 仓库根目录，.git文件夹不可见
最稳的操作路径：按 Ctrl+Shift+P（Win/Linux）或 Cmd+Shift+P（macOS），输入 Git: Compare Working Tree with Index 并执行——名字就写明了对比对象，不会歧义。
git ls-files --stage 能看出什么关键信息
git ls-files --stage 输出的是暂存区的底层快照，每行格式为：<mode> <object hash> <stage> <path>。其中 mode 是重点：以 100644（普通文件）、100755（可执行）、120000（符号链接）开头的，才代表真正被暂存的文件。
这个命令不适合日常快速查看，但它能解决几个隐蔽问题：
- 确认某个文件是否真的在暂存区（比如
git add -f强制添加了忽略文件，git status不显示，但git ls-files --stage会列出来） - 发现冲突残留：合并冲突时，同一文件可能以多个 stage 值（1/2/3）同时存在，
git ls-files --stage | grep filename能一眼揪出 - 排查 .gitignore 生效异常：如果某文件本该被忽略，却出现在输出里，说明它曾被
git add -f过，已进入暂存区，.gitignore 对它失效
真正难的不是记住命令，而是理解“暂存区”不是个可视化列表，而是一个由 object hash 组成的索引——git ls-files --stage 是唯一让你直面这个索引的入口。
