xml文件无内置只读属性，实际只读依赖操作系统权限；程序应启动时探测可写性，写入时采用原子替换，权限设置应在部署环节统一管控而非构建环节。
XML 文件本身没有“只读”属性，靠操作系统权限控制
XML 只是文本文件，readonly 这种标记在 XML 格式里不存在，也不被解析器识别。真正起作用的是文件系统层面的只读标志（如 Linux 的 chmod -w，Windows 的文件属性勾选“只读”）。程序能否修改它，取决于运行时进程是否有写权限。
- 在 Linux/macOS 上：
chmod 444 config.xml（去掉所有用户的写权限），注意别锁死自己——后续更新配置需先改权限再写 - 在 Windows 上：右键文件 → “属性” → 勾选“只读”，或命令行用
attrib +R config.xml - Java 程序里调用
File.setReadOnly()是在尝试设置 OS 层权限，但可能因用户权限不足而静默失败，务必检查返回值 - Node.js 的
fs.chmodSync()同样依赖进程权限，容器环境（如 Docker）中若以非 root 用户运行，很可能 chmod 失败且不报错
程序启动时校验 XML 是否可写，提前暴露问题
等程序运行中去写才发现权限不够，往往已走到关键路径，错误难定位。更稳妥的做法是在加载配置后、业务逻辑前做一次轻量探测。
- Python 示例：
os.access("config.xml", os.W_OK)返回False就该立刻 log 警告并退出 - .NET 中可用
new FileInfo("config.xml").IsReadOnly，但它只反映 Windows 的“只读”属性位，不反映实际写能力（比如 NTFS 权限禁止写但属性位未设），建议配合File.OpenWrite()尝试打开再关闭 - 不要只测存在性（
os.path.exists），存在 ≠ 可写；也不要只测读权限，读得通不代表写得进
避免程序内部“覆盖写”，改用原子写入 + 重命名
即使文件设了只读，有些程序仍会先读取、内存修改、再 open(..., "w") 覆盖原文件——这时 OS 权限拒绝会抛出 PermissionError 或 AccessDeniedException。但更隐蔽的问题是：没设只读时，意外覆盖直接发生，连备份都没有。
- 正确做法是写入临时文件（如
config.xml.tmp），再用os.replace()（Python）或Files.move()（Java NIO）原子替换原文件 - 这样即使中途崩溃，原配置仍在，不会出现“半截坏文件”
- 注意：Windows 下
rename跨卷会失败，临时文件必须和原文件同盘；Linux 下则无此限制 - 如果真需要运行时修改配置，优先考虑环境变量或数据库，而不是硬写 XML 文件
IDE 或构建工具自动改权限？小心 CI/CD 流水线翻车
有人在 build.gradle 或 Makefile 里加 chmod 444，以为一劳永逸。但 CI 环境常以 root 运行，改完权限后，后续步骤（比如打包、部署）可能因无法读取（极少见）或更常见的是——部署脚本自己又给改回去了。
- 权限设置应由部署环节统一管控，而非构建环节。构建产物保持默认权限（通常是 644），部署时根据目标环境策略赋权
- Docker 镜像中用
COPY --chown或RUN chmod设置，但要确认基础镜像用户 UID 匹配，否则chmod无效 - Git 不跟踪文件权限变更（除非用
git update-index --chmod=+x），所以本地设了只读，别人 clone 下来还是可写——别依赖 Git 传权限
