.gitignore 必须放在 Git 仓库根目录且命名为 .gitignore 才生效；若文件已被跟踪，需先用 git rm --cached 移除再加入忽略规则；通配符语法朴素，路径以 / 开头表示根目录匹配；全局忽略不作用于已跟踪文件；IDE 生成的常遗漏关键项，应参考官方模板并显式添加构建产物和环境文件。
gitignore 文件写在哪才生效
必须放在 Git 仓库根目录下，文件名是 .gitignore（开头带点，且全小写）。Git 只认这个路径和名字，放错位置比如子目录里、或者叫 gitignore.txt，统统无效。
常见错误现象：git status 依然显示要提交的文件，改了 .gitignore 也没用——大概率是文件已经被 Git 跟踪过了，或者 .gitignore 不在仓库根目录。
- 新建仓库时，立刻创建
.gitignore，再执行git add .，能避免误跟踪 - 已有文件被跟踪了？先用
git rm --cached <file>把它从暂存区移除（保留本地文件），再加进.gitignore - 想验证某文件是否会被忽略？运行
git check-ignore -v <file>，它会告诉你匹配了哪一行规则、来自哪个.gitignore
通配符和路径写法容易踩坑
.gitignore 不是 shell，也不是正则，它的语法很朴素：每行一条规则，支持 *（匹配任意字符，不跨 `/`）、**（匹配多级目录）、?（匹配单个字符）、[abc]（字符集），但不支持 +、{} 或捕获组。
路径以 / 开头表示从仓库根开始；不加斜杠则表示“任意层级匹配”。这点特别容易混淆。
-
node_modules→ 匹配所有目录下的node_modules（包括src/node_modules） -
/node_modules→ 只匹配根目录下的node_modules -
dist/→ 忽略所有dist目录及其内容（结尾加/表示目录） -
*.log→ 忽略所有.log文件，但不会影响app.log.bak（因为*不跨/，而.是普通字符） - 注释用
#，空行会被忽略，规则顺序重要：后面覆盖前面（如果同一文件被多次匹配）
全局忽略只影响新仓库，不清理旧记录
用 git config --global core.excludesfile ~/.gitignore_global 可设全局忽略规则，适合个人常用文件如 ~/.DS_Store、Thumbs.db。但它只对「尚未被 Git 跟踪」的文件起作用。
常见错误现象：设置了全局忽略，但老项目里 .DS_Store 还是出现在 git status 里——因为这个文件早被提交过，Git 依然认为它是受控文件。
- 全局配置不会自动删掉已跟踪的文件，得手动
git rm --cached清理 - 团队协作时，别依赖全局配置，把通用规则（如编辑器临时文件）写进项目级
.gitignore - 查看当前生效的全局路径：
git config --get core.excludesfile
IDE 自动生成的 .gitignore 可能漏关键项
VS Code、WebStorm 等会提示生成 .gitignore，但它们通常只覆盖自身临时文件（如 .vscode/、.idea/），不考虑项目实际构建产物或敏感配置。
比如 React/Vue 项目默认生成 dist/，但若你用 Vite，还可能有 .vite/；Python 项目写了 __pycache__/，却漏了 *.pyc 和 .pytest_cache/。
- 优先参考对应语言/框架的官方推荐模板（如 GitHub 的 gitignore templates 仓库）
- 构建产物目录（
build/、out/、.next/）务必显式添加，别指望 IDE 猜中 - 环境变量文件（
.env.local、config.local.js）一定要加，否则容易误提交密钥 - 检查
git status -u（显示未跟踪文件），确认没有漏网之鱼
最麻烦的不是写不对，而是写对了但文件早已被 Git 记住——这时候得记清两件事：--cached 是解绑的关键参数，check-ignore -v 是唯一靠谱的验证方式。
