缓存文件写入失败这个报错，搭建网站、部署服务的人基本都遇到过。报错提示形式差别很大，有的直接提示缓存目录不可写，有的抛出failed to open stream: Permission denied，还有的没有任何报错提示，页面空白或者持续加载，只能翻日志才能定位到缓存写入异常。问题本身不算复杂，但排查很容易走弯路，能触发写入失败的原因相当多。
权限问题是最常见的情况。缓存目录的属主和PHP、Node进程运行用户不匹配，比如目录归属root账号，但进程用www-data运行，自然无法写入。Linux系统执行ls -ld查看目录权限，大多是755或者700，进程用户没有写入权限。两种处理方式，用chown修改目录归属为进程用户，或者chmod添加写权限。chmod 777只能作为最后的应急手段，生产环境优先用chown解决，不要直接全开权限。修改权限之后，缓存目录内部旧文件也要一并处理，有时候目录权限正常，但目录内文件还是root所属，依旧无法写入。
磁盘空间占满也是高频诱因。执行df -h查看，缓存所在分区或者根分区使用率100%，任何写入操作都会失败。磁盘满分两种，单纯存储空间耗尽，或是inode耗尽。df -i可以查看inode状态，IUse%达到100%，代表大量小文件耗尽inode。缓存目录堆积几十万零碎文件是很常见的场景，清理后就能释放inode。清理的时候不要直接执行rm -rf *，文件数量过多会导致命令卡死，用find搭配-delete或者分批删除更稳妥。
open_basedir限制很容易踩坑。PHP配置开启open_basedir之后，如果缓存目录不在允许访问路径列表，写入请求会直接拦截。典型报错是open_basedir restriction in effect，但不少框架会把这个错误包装成缓存写入失败，看起来和权限故障一模一样。查看php.ini的open_basedir配置，确认缓存路径包含在内。虚拟主机环境这种限制很普遍，无法修改php.ini的话，可以把缓存目录迁移到允许路径，或者联系主机服务商调整配置。
SELinux、AppArmor也会拦截写入操作。CentOS系列系统默认开启SELinux，缓存目录安全上下文类型不对，就算权限设为777也无法写入。getenforce查看状态，返回Enforcing代表处于开启状态。临时执行setenforce 0切换为Permissive模式测试，故障消失就代表是SELinux导致。永久修复需要semanage fcontext搭配restorecon给缓存目录打上正确安全标签，也可以直接关闭SELinux，但关闭前要评估安全风险。Ubuntu系统的AppArmor逻辑类似，查看/var/log/kern.log，检索denied相关日志记录。
缓存路径配置错误也不少见。配置文件填写相对路径，一旦进程工作目录发生变化，文件会写入别的位置，甚至找不到目录。相对路径依赖进程当前工作目录，不同运行方式对应的工作目录不一样。改成绝对路径基本能规避这类问题。还有一种情况，缓存目录被手动删除，程序不会自动重建目录，写入直接失败，手动重建目录并配置好权限，一般就能恢复。
并发写入偶尔会造成写入失败。多个请求同时向同一个缓存文件写入，没有加锁机制，文件互相覆盖或者损坏，后续读取解析失败，最终表现为写入报错。这类问题一般在流量上涨之后才暴露，低访问量时段一切正常。解决方案取决于所用框架，部分框架支持文件锁，还有方案是切换Redis、Memcached作为缓存后端，绕开文件系统层面的并发冲突。缓存体量不大的场景，给写入操作增加简单flock文件锁也能缓解。
Windows环境的权限排查更麻烦。IIS运行PHP，缓存目录需要给IIS_IUSRS或者NETWORK SERVICE分配写权限，权限继承经常失效，需要手动进入安全选项卡关闭继承，单独添加写入权限。Windows还有一个坑，杀毒软件实时扫描锁定缓存文件，阻断写入，把缓存目录加入杀毒软件排除列表即可解决。
排查建议按这个顺序操作：先读取错误日志，确认写入失败的文件和路径；再用ls -ld查看目录权限、属主；df -h和df -i检查磁盘与inode；getenforce检查SELinux；php -i | grep open_basedir查看路径限制。大部分故障在前三步就能定位。如果日志只提示缓存写入失败，没有详细信息，开启框架调试模式，或者调高PHP错误级别，输出具体warning信息。缺少详细信息的报错没有排查价值，先拿到失败路径和根因，再针对性处理。