根本原因是linux与windows在路径分隔符、web服务器用户权限、当前工作目录初始值、web服务器配置及进程运行用户权限模型上的差异。
Linux下file_get_contents读取本地文件失败，但Windows正常？
根本原因不是函数本身差异，而是路径分隔符和权限模型不同。Linux用/，Windows兼容\和/；更重要的是，PHP在Linux下以Web服务器用户（如www-data或apache）身份运行，该用户可能无权访问你写的绝对路径目录。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 统一用
dirname(__FILE__) . '/data/config.json'构造相对路径，避免硬写C:\或/var/www/ - 检查目标文件权限：
ls -l /path/to/file，确保Web用户有读权限（常见修复：chmod 644 file.json或chown www-data:www-data file.json） - 禁用
open_basedir限制前先确认是否真有必要——它常被忽略却导致Linux下file_get_contents静默失败
Windows能用realpath()解析..\，Linux却返回false？
这不是realpath()的问题，而是当前工作目录（CWD）在不同系统下初始值不同：Apache on Windows常以脚本所在目录为CWD，而Linux下可能以DocumentRoot或/为起点，导致../向上越界。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 不要依赖
getcwd()来拼路径，改用__DIR__（PHP 5.3+）或dirname(__FILE__) - 若必须用
realpath()，先chdir(__DIR__)再调用，避免CWD干扰 - 注意
realpath()在路径不存在时返回false，Linux下更严格——Windows有时会“宽容”地返回部分解析结果
fopen('php://input')在Linux Nginx + PHP-FPM下为空，Windows Apache正常？
本质是Web服务器配置差异：Nginx默认不将原始请求体传给PHP-FPM，而Apache的mod_php直接接入SAPI层。这不是PHP跨平台问题，是中间件链路断点。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- Nginx配置中确认存在：
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;和fastcgi_pass php-fpm; - 关键项：
client_max_body_size（Nginx）和post_max_size（PHP）需同步调大，否则Linux下大请求直接被截断，php://input自然为空 - 调试时用
var_dump($_SERVER['REQUEST_METHOD'], $_SERVER['CONTENT_TYPE'])先确认是否真进了POST路由，而非被Nginx 405或413拦截
用shell_exec('whoami')在Windows返回SYSTEM，Linux返回www-data，影响文件操作？
是的，而且影响是根本性的。Windows下Web进程常以高权限账户运行，掩盖了权限问题；Linux则强制最小权限原则。同一段代码在Windows能写/tmp，在Linux可能因www-data无权写/var/www/html/cache而失败。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 所有涉及写操作的目录，明确用
is_writable()校验，别靠file_exists()或异常捕获蒙混 - 缓存、上传、日志等目录应设为Web用户可写但不可执行：
chmod 755 dir（目录）+chmod 644 file（文件） - 避免用
shell_exec调外部命令做I/O——Linux下SELinux或Capability限制会让它彻底失效，Windows又容易引发权限提升风险
跨平台路径与权限问题最易被忽略的点：开发时在Windows上一切正常，上线后Linux报错却不报具体路径或权限信息，往往卡在error_log没开或display_errors=Off。务必在Linux测试环境开启log_errors=On并检查error_log路径权限。
