真正防误改或恶意覆盖必须用 chattr +i，它通过内核级拦截实现 root 也无法绕过的硬只读；chmod 444 仅限制普通用户，root 仍可覆盖，仅适用于明确接受 root 可修改的场景。
不能只用 chmod 444 —— 它防不住 root，真要锁死必须用 chattr +i。
chmod 444 只对普通用户有效，root 仍可覆盖
执行 chmod 444 /etc/my.conf 后，普通用户执行 echo "x" > /etc/my.conf 会失败，但 sudo echo "x" > /etc/my.conf 或 sudo tee /etc/my.conf 依然成功。常见翻车场景：
- 运维脚本用
chmod 444锁配置，结果 cron 以 root 运行时直接覆盖 - 容器内应用默认以 root 启动，
chmod对它完全无效 - SELinux 关闭时，
chmod是唯一防线；一旦有更高权限上下文（如 root、CAP_SYS_ADMIN），它就失效
chattr +i 才是真正的“硬只读”
chattr +i 设置的是文件系统级不可变属性，内核在 write 系统调用阶段拦截，连 root 也无法绕过。生效后：
-
echo "x" > file、vim file、rm file、mv file new全报Operation not permitted - 必须用 root 执行：
sudo chattr +i /path/to/file - 验证是否生效：
lsattr /path/to/file输出末尾应含i（如----i--------e---） - 解除锁定只能显式执行：
sudo chattr -i /path/to/file，没有“临时禁用”机制
目录设只读要特别小心
对目录执行 chattr +i 会锁死整个目录结构：无法新建、删除、重命名任何子项。但已有文件内容仍可被修改——除非它们也单独加了 +i。正确做法是：
- 给目录本身加
+i（防rm -rf、mv） - 对关键子文件（如
config.json、私钥）单独加+i - 日志类文件别加
+i，改用sudo chattr +a /var/log/app.log允许追加但禁止覆盖 - 避免
sudo chattr -R +i /dir—— 极难恢复，一不小心卡住/etc下某个子目录就可能瘫痪系统
什么时候还该用 chmod？
仅当目标明确是“限制普通用户，且接受 root 可覆盖”时才用 chmod。典型场景：
- 共享开发环境里，防止同事误改公共配置模板（所有人都是普通用户）
- 构建阶段临时锁定源码文件，避免构建脚本意外写入
- 配合
install -m 444分发只读资源（如证书、文档） - 注意：
chmod 644和444对文件内容写入效果一致（无执行位时，6 和 4 的差异不生效），但语义上444更准确表达“纯只读”意图
真正防误改或恶意覆盖，chattr +i 是唯一可靠选择；但它的代价是：解除锁定必须显式操作，且一旦加错位置（比如加到正在写的日志目录），服务可能直接挂掉。别图省事跳过 lsattr 验证。
