先说几个核心判断：在 CentOS 上使用 Node.js 操作文件系统，表面看似容易，但实际隐藏着不少潜在陷阱。权限配置、运行上下文、系统资源限制……任何一个环节处理不当，都可能导致应用突然崩溃。下面我们就将这些常见限制逐一分析，看看问题究竟出在哪里。
1. 文件与目录权限限制
CentOS 严格遵循 Linux 文件系统权限模型。Node.js 的 fs 模块在执行读取、写入、删除、修改等操作时，必须首先通过“用户权限验证”——当前运行用户对目标文件或目录必须拥有对应的读（r）、写（w）、执行（x）权限。如果权限不匹配，系统会抛出 EACCES（权限不足）或 EPERM（操作不允许）错误。举个例子：如果 Node.js 应用以普通用户身份运行，却试图访问 /root 目录下的文件，结果只能是“被拒绝”。即使应用本身具备权限，但如果文件被设置为只读（例如 chmod 444），写入操作同样会失败——系统不会给予任何通融。
2. 特权操作需要 root 权限
某些系统级文件操作，例如修改文件所有者（chown）、更改权限（chmod）、删除非空目录（rmdir），天生就要求超级用户（root）身份。如果普通用户通过 Node.js 调用这些操作，系统会直接返回 EPERM 错误。比如使用 fs.chownSync('/path/to/file', 0, 0) 将文件所有者改为 root，就必须通过 sudo 启动应用，或者借助 sudo 执行特定命令——普通用户无权干预这类操作。
3. 最大打开文件数限制
Linux 系统通过 ulimit -n 限制每个进程能够同时打开的文件描述符数量，默认值通常仅为 1024。如果您的 Node.js 应用需要处理大量并发请求，或者频繁读写文件（例如日志服务、文件缓存），很容易触及这个上限，并遇到 EMFILE（Too many open files）错误。如何应对？临时调整：直接执行 ulimit -n <新限制>（注意只对当前会话生效）。若要永久生效，则需要修改 /etc/security/limits.conf，添加类似 * soft nofile 65535 的配置行。
4. SELinux 上下文限制（如果开启的话）
CentOS 默认启用 SELinux（安全增强型 Linux），它的访问控制独立于传统权限模型。只要 SELinux 处于 Enforcing 模式，即便文件权限看起来没有问题，Node.js 应用也可能因为 SELinux 上下文不匹配而被拒绝访问。举例来说：应用目录的上下文被标记为 httpd_sys_content_t（用于 Web 内容），但 Node.js 尝试向该目录写入数据，系统同样返回 EACCES。此时可用 ls -Z 查看当前上下文，使用 chcon 修改它（例如 chcon -R -t httpd_sys_rw_content_t /path/to/dir），或者临时将 SELinux 切换为 Permissive 模式以便排查问题——但切勿在生产环境中这样做。
5. 文件路径与存在性检查
Node.js 的 fs 操作对路径要求十分严格——路径不存在就会报错。例如，尝试删除一个不存在的文件（fs.unlink('/nonexistent/file')），系统返回 ENOENT（No such file or directory）；如果路径是一个目录，却试图以写入模式打开它（fs.open('/path/to/dir', 'w')），则会得到 EISDIR（Is a directory）错误。防患于未然的做法：操作前先用 fs.existsSync() 或 fs.stat() 检查路径状态，确认它确实存在且类型正确。
6. 文件占用冲突
如果文件正被其他进程（比如文本编辑器、备份工具、系统服务）占用，Node.js 尝试写入或删除时就会失败，返回 EBUSY（Device or resource busy）错误。遇到这种情况没有捷径——首先需要找到并关闭那个占用文件的进程，然后再执行您的操作。
