git config --list --show-origin 能立刻暴露冲突点，它按工作区＞仓库＞全局＞系统优先级顺序输出所有配置项及其来源文件路径，同名键（如user.name）在多层级出现即表明存在覆盖，最后一行值生效。
git config --list --show-origin 能立刻暴露冲突点
直接运行 git config --list --show-origin，所有配置项会连带来源路径一并输出。系统级、全局级、仓库级配置混在一起时，靠肉眼扫 git config --list 很容易漏掉同名键（如 user.name）在不同层级的值差异。而 --show-origin 会明确标出每行来自哪个文件，比如：
file:/etc/gitconfig core.autocrlf=true file:/home/user/.gitconfig user.name=Zhang San file:.git/config user.name=project-team
看到同一 key 出现在多个路径，就说明存在潜在覆盖——Git 永远取优先级最高的那个，不会报错也不会警告。
/etc/gitconfig 和 ~/.gitconfig 冲突时，谁赢？
Git 配置优先级是硬编码的：工作区 > 仓库 > 全局 > 系统。也就是说，/etc/gitconfig（系统级）优先级最低，~/.gitconfig（全局级）更高一级。一旦你在全局配置里设了 user.email，系统级的同名设置就完全失效，哪怕它写得更早、路径更“根”。
全面审计 Tasks.md 和 Flatnotes 的一致性与准确性；以 GitHub (gh CLI) 为事实来源检测过时笔记/卡片及缺失链接，并生成报告及可选修复计划。
- 系统级配置只对全新用户或未设全局配置的场景起作用
- 如果你用
sudo git config --system xxx改过系统配置，但普通用户又设置了全局配置，那普通用户根本感知不到系统级的存在 - Windows 上系统级路径可能是
C:\Program Files\Git\etc\gitconfig，注意权限问题——普通用户通常无权修改它
删错配置文件可能导致 Git 命令直接报错
误删 ~/.gitconfig 不会崩，但 Git 会退回到系统级或默认行为；而删掉 /etc/gitconfig 在某些 Linux 发行版或 CI 环境中，可能让 git init 或 git clone 报 fatal: unable to read config file '/etc/gitconfig': No such file or directory ——这不是 Git 崩溃，而是它坚持要读这个路径，哪怕为空。
- 不要手动编辑或删除
/etc/gitconfig，除非你明确知道该环境由你全权维护 - 想清空某一层配置，用
git config --global --unset user.name比直接删文件安全得多 -
git config --global --edit是安全打开全局配置的方式，它会自动处理文件不存在时的创建逻辑
CI/CD 流水线里系统级配置常被悄悄覆盖
很多 CI 平台（如 GitHub Actions、GitLab CI）默认把 Git 配置为系统级生效，但会在 job 启动时注入全局配置（比如用 git config --global user.email）。这时候你本地 ~/.gitconfig 完全不生效——因为 runner 是干净容器，没有你的家目录。
- 流水线脚本里别假设
--global配置已存在，每次都要显式设置 - 如果用
git config --system在 CI 中设值，大概率失败（权限不足），应改用--global或直接写入$HOME/.gitconfig - 验证方式：在 CI 脚本里加一行
git config --list --show-origin，看实际加载了哪些路径
真正容易被忽略的是：Git 读配置是 lazy 的，只有用到某个 key 时才按优先级链查一次。所以即使你改了 /etc/gitconfig，只要没碰过那个 key，就不会触发覆盖效果——这也意味着，问题可能长期潜伏，直到某次提交突然用错邮箱或换行策略。
