切换分支时仅内容实际变化的文件mtime会被更新，Git通过对比工作区与目标提交内容决定是否重写文件；空目录、.gitignore文件及未跟踪文件mtime不变；git status显示modified不依赖mtime而是基于内容hash与index快照。
切换分支时，工作区文件的修改时间（mtime）会变，但不是因为 Git 主动改了它，而是由检出动作触发的文件系统写入行为导致的。
git checkout / git switch 切换分支时，哪些文件的 mtime 会被更新
只有那些「内容实际发生变化」的文件，其 mtime 才会被更新。Git 在切换分支时，会对比当前工作区文件与目标提交中对应路径的内容：
- 如果文件内容相同，Git 不会重写该文件，
mtime保持不变 - 如果文件内容不同（包括新增、删除、修改），Git 会用目标提交中的版本覆盖工作区文件 → 触发文件系统写入 →
mtime更新为当前时间 - 空目录、.gitignore 中的文件、未被跟踪的文件，不受影响，
mtime不变
git restore 和 git switch --discard-changes 对 mtime 的影响差异
git restore 是显式还原文件内容，而 git switch 是分支切换操作；两者触发 mtime 更新的逻辑不同：
-
git restore <file>：只更新指定文件，且仅当目标内容与当前不同时才写入 → 只有被还原的文件 mtime 变 -
git switch -c new-branch或git switch main：按需检出整个工作区，所有内容变更的文件 mtime 都会变 -
git switch --discard-changes：强制丢弃暂存区和工作区改动，再切换 → 等效于先git restore -s@{0} -S -W .再切换 → 大量文件 mtime 可能批量刷新
为什么有些文件 mtime 没变，但 git status 显示 modified
这是常见误解点：Git 判断文件是否被修改，**不依赖 mtime**，而是基于三个数据：
Lovefromio Github
下载
使用 `gh` CLI 与 GitHub 交互。通过`gh issue`、`gh pr`、`gh run` 和 `gh api` 管理 issue、PR、CI 运行以及高级查询。
- 文件当前的
stat信息（含 mtime、inode、size） - 暂存区（index）中记录的该文件上次写入时的
stat快照 - 工作区文件的实际内容 hash（必要时计算）
所以会出现：mtime 没变，但文件内容被外部编辑器悄悄保存过（比如 IDE 自动格式化），导致内容 hash 变了 → git status 显示 modified。反过来，如果只是 touch 一个已暂存文件，mtime 变了但内容没变，Git 通常仍认为“未修改”（除非开启 core.trustctime 且 ctime 也变了）。
想让 mtime 尽量不干扰构建或缓存，该怎么办
某些构建工具（如 Make、Rust 的 cargo）或 IDE 会依赖 mtime 做增量判断，频繁切换分支可能误触发全量重建。可考虑：
- 用
git worktree隔离不同分支的工作区 → 各自独立 mtime，互不影响 - 禁用 Git 的 stat 缓存（不推荐）：
git config --local core.stat false，但会导致每次git status变慢 - 接受 mtime 变更事实，在构建脚本中改用内容 hash 或 Git commit ID 作为缓存 key
- 避免在生产构建流程中执行分支切换；CI 场景应始终用
git clone --depth=1 --branch=xxx或git fetch && git reset --hard替代git switch
真正容易被忽略的是：mtime 变化本身不可控，但 Git 的状态判定逻辑完全不依赖它 —— 你看到的「modified」永远是内容或暂存状态的真实反映，不是 mtime 的副作用。
