· 全部指南
理解 chmod 的两种权限表示法
Linux 文件权限可通过八进制数字（如 755）或符号表示（如 u+x）设置。数字法中三个位分别代表所有者、组和其他用户的权限，每个数字对应读（4）、写（2）、执行（1）权限之和。符号表示法则更直观，用 u/g/o/a 指定用户类型，+/-/= 设置权限增减。使用 Towalles 的 chmod-calculator 工具可在浏览器本地快速换算不同表示法，避免隐私数据外泄。
常见权限组合中，755 适合可执行程序（所有者完全控制，其他用户只读执行），644 适用于普通文件（所有者读写，其他用户只读）。特殊权限如 setuid（4000）需要谨慎使用。符号表示法适合临时调整，如给脚本添加执行权限：chmod +x deploy.sh，而数字法则更适合精确控制整个项目的权限结构。
Git 中的文件权限处理
Git 只记录文件的「可执行位」权限差异，普通文件的读写权限不会被追踪。当你在本地修改了文件权限（如 chmod 644 → 600），Git status 可能显示「old mode 100644 new mode 100600」。使用 git-memo 工具可以快速记录这些变更，避免因权限问题导致部署失败。注意：Git 仓库中应避免提交含有敏感权限（如 777）的文件。
修复 Git 权限问题常用 git config core.fileMode false 忽略本地权限变更，或使用 git update-index --chmod 显式更新索引。部署时若需要保留特定权限，应在部署脚本中加入 chmod 命令。对于团队项目，建议在文档中明确权限规范，或通过 .gitattributes 文件统一处理特定文件类型的权限。
可执行脚本的权限实践
Shell/Python 等脚本需要同时满足两个条件才能执行：可执行权限位（x）和正确的解释器声明（如 #!/bin/bash）。部署时常见问题包括：通过 Git 克隆后脚本失去执行权限，或 Windows 系统开发的脚本在 Linux 部署时出现换行符问题。解决方案是在提交前确保脚本有执行权限，并在部署脚本中显式设置 chmod +x。
对于自动化部署，推荐在 CI/CD 流水线中增加权限修复步骤。例如在 GitHub Actions 中添加 find . -name "*.sh" -exec chmod +x {} \;。敏感脚本应限制为 700（仅所有者可执行），日志文件建议设置为 644。使用容器部署时，注意在 Dockerfile 中正确设置 WORKDIR 文件的权限。
部署场景的权限控制策略
不同部署环境需要不同的权限策略：生产环境应遵循最小权限原则，开发环境可能需要宽松设置以便调试。Web 服务器文件通常设置为 644（文件）和 755（目录），确保 Nginx/Apache 用户有足够但不过度的访问权限。使用 umask 命令可以控制新创建文件的默认权限，避免每次手动调整。
对于需要 sudo 权限的部署脚本，建议拆分为「准备阶段」（普通用户执行）和「特权阶段」（通过 sudo 执行具体命令）。日志记录所有权限变更操作，方便审计。Towalles 的所有权限计算工具均运行在浏览器本地，特别适合处理含敏感信息的部署方案设计，确保权限配置过程零数据泄露。
Git 跟踪可执行位，不是完整 POSIX ACL
git update-index --chmod=+x 对仓库内脚本很重要，但无法复现复杂 NFS ACL。所需 umask 与部署步骤应另行文档化。
模式位里有密钥？
没有——但工作区里对所有人可读的密钥文件仍是事故。保持 .env 被忽略；CI 使用密钥管理器。
评审
PR 大量翻转文件模式时要问为什么。意外的模式噪声会掩盖真改动，并在 Windows / Unix 检出上表现不同。
Git 模式位审阅
动生产前先写操作程序：输入、期望输出、负责人与回滚。Towalles 上的工具便于本地检查样例，不能替代变更控制。
前置条件
- 有代表失败案例的脱敏 fixture。
- 清楚谁是真相来源（应用、网关、CMS 或网络设备）。
- 能在非生产环境或用合成数据复现问题。
步骤
- 用 fixture 复现，记录精确命令或 UI 路径。
- 按需用格式化、哈希或解析工具与已知正确样例对照。
- 做最小修复；同一变更里避免顺手重构。
- 补充回归测试或清单项，避免下一任 on-call 重复踩坑。
- 更新 runbook：症状 → 检查 → 修复。
善后
观察 24–72 小时错误率与支持工单。若做过一次性数据修复，安排后续防止复发。工单里保留截图与哈希，不要留真实密钥。
反模式
- 把生产密钥贴到公开页面「只是看一下」。
- 上线却不写回滚说明。
- 把本地绿色演示当成多区域生产的证明。