最常引发问题的是换行符和路径分隔符；它们会导致include失败、file_get_contents读出异常字符、Composer报错及Git提交混乱，需配置Git的core.autocrlf为input（Linux/macOS）或true（Windows）。
Windows 和 macOS/Linux 之间直接拷贝 PHP 源码，最常引发问题的不是语法或扩展，而是换行符和路径分隔符——它们会让 include 失败、file_get_contents 读出异常字符、Composer 安装报错，甚至让 Git 提交变混乱。
Git 配置必须设为 core.autocrlf=input（Linux/macOS）或 core.autocrlf=true（Windows）
Git 默认行为在跨平台时会偷偷转换换行符，导致 PHP 脚本里出现 \r\n 混入 开头，触发“Headers already sent”错误；或者 __DIR__ . '/lib/foo.php' 在 Windows 上拼出 C:\project\lib\foo.php 却被当成 Unix 路径处理。
- macOS/Linux 用户执行：
git config --global core.autocrlf input - Windows 用户执行：
git config --global core.autocrlf true - 已有仓库需重置索引：
git rm --cached -r . && git add . - 检查当前配置：
git config core.autocrlf，确保不是false
dirname(__FILE__) 和 __DIR__ 是安全的，但拼接路径必须用 DIRECTORY_SEPARATOR
PHP 的 __DIR__ 始终返回本地风格路径（Windows 用 \，Linux/macOS 用 /），但硬编码 '/lib/config.php' 或 '\inc\utils.php' 会导致跨平台包含失败。
- 正确写法：
require __DIR__ . DIRECTORY_SEPARATOR . 'lib' . DIRECTORY_SEPARATOR . 'config.php'; - 更推荐用
str_replace('/', DIRECTORY_SEPARATOR, 'lib/config.php')统一转换已知 Unix 风格路径 - Composer 自动处理的
autoload路径（如 PSR-4）通常安全，但自定义files加载项仍需手动适配 - 避免用
realpath()做路径拼接起点——它在 Windows 上可能返回带盘符的绝对路径，与相对 require 不兼容
文件内容含换行符时，fgets()、file() 和 explode("\n", $str) 行为不一致
PHP 函数对换行符的容忍度不同：Windows 文件用 \r\n，Linux/macOS 用 \n，若用 explode("\n", $content) 处理 Windows 文件，末尾会多出 \r 字符，导致 trim() 后仍残留；file() 默认按本地换行符分割，但若文件是跨平台复制而来且未被 Git 正确转换，结果不可靠。
立即学习“PHP免费学习笔记（深入）”；
- 读取文本行优先用
file($path, FILE_IGNORE_NEW_LINES | FILE_SKIP_EMPTY_LINES) - 手动分割字符串时统一转成
\n：str_replace(["\r\n", "\r"], "\n", $content) - 写入文件务必用
PHP_EOL而非"\n"，尤其日志或生成配置文件场景 - 检查换行符实际内容可用：
bin2hex(file_get_contents($file))，看末尾是0a还是0d0a
真正麻烦的不是单个函数或符号，而是换行符和路径分隔符问题往往藏在边缘场景里：CI 构建时环境变量注入、Docker 容器挂载卷的文件系统差异、IDE 自动保存格式设置、甚至 FTP 工具的传输模式（ASCII vs Binary）。一旦出问题，现象分散，得从 var_dump(pathinfo(__FILE__)) 和 ord($str[0]) 这类底层输出开始查起。
