Linux 严格依赖用户/组+权限位，Windows 依赖 ACL 且 PHP 进程身份不同，导致 storage、bootstrap/cache、.env 等目录跨平台迁移后频繁出错，必须按系统规则重设权限。
Windows 和 Linux 在 Laravel 部署中对文件权限的理解和执行逻辑完全不同，不是“设了可写就真能写”，而是系统底层机制决定能否成功。核心差异在于：Linux 严格依赖用户/组+权限位（rwx），而 Windows 主要靠 ACL 控制，且 PHP 进程在两者下运行身份也不同——这直接导致 storage、bootstrap/cache、.env 等关键目录在跨平台迁移后频繁出错。
storage 和 bootstrap/cache 目录的写权限必须按系统规则重设
Linux 下，Web 服务器进程（如 www-data、nginx 或 apache）必须对 storage/logs、storage/framework/views、bootstrap/cache 拥有实际写权限；Windows 则更关注当前登录用户或 IIS/PHP-CGI 进程是否具备“完全控制”权限。
- Linux 推荐命令：sudo chown -R www-data:www-data storage bootstrap/cache，再执行 sudo chmod -R 755 storage bootstrap/cache（部分场景需 775）
- Windows 若用 XAMPP/WAMP，确保 Apache 服务以当前用户身份运行，或右键目录 → “属性” → “安全” → 编辑权限，勾选“修改”和“写入”
- 别信“我刚复制过去是可写的”——从 Windows 打包传到 Linux 的文件，UID/GID 会丢失，权限位也可能被 tar 默认 strip，必须重设
.env 文件权限与读取行为不一致
Laravel 通过 DotEnv 加载 .env，但加载时机和失败静默程度因系统而异。Linux 下若 .env 权限为 600 且属主不是 Web 进程用户，config:cache 会跳过加载且不报错；Windows 下则常因路径解析或 BOM 头导致读取失败。
- Linux 生产环境建议权限设为 644，属主为 Web 用户（如 chown www-data:www-data .env）
- Windows 上用记事本保存 .env 容易带 UTF-8 BOM，改用 VS Code 或 Notepad++ 并选“UTF-8 无 BOM”格式保存
- 验证是否生效：运行 php artisan tinker，输入 env('DB_DATABASE')，看是否返回预期值
临时目录与字体缓存目录的可写性容易被忽略
DOMPDF、Excel 导出、队列日志等组件会在运行时创建临时文件。Linux 的 /tmp 默认可写，但若配置了自定义 temp_dir（如 storage/temp），就必须手动授权；Windows 的 %TEMP% 路径虽宽松，但 php artisan serve 启动时若未提权，仍可能写失败。
- 统一用 sys_get_temp_dir() 获取系统级临时路径，避免硬编码
- DOMPDF 字体缓存目录（如 storage/fonts）需确保 Web 进程可写，且字体文件名大小写与 config/dompdf.php 中 'default_font' 值严格一致（Linux 敏感，Windows 不敏感）
- 测试方法：在路由中临时加一行 file_put_contents(sys_get_temp_dir().'/test.tmp', 'ok');，访问触发，再检查文件是否存在
部署脚本中的权限操作不能跨平台复用
一个在 Linux 上跑通的 deploy.sh，直接扔进 Windows PowerShell 就会失败——chmod、chown 在 Windows 原生不可用，而 icacls 又无法在 Linux 执行。自动化部署必须区分平台逻辑。
- 推荐在部署流程中加入判断：if [ "$(uname)" = "Linux" ]; then chown ...; fi
- 使用 Laravel Envoy 或 Envoyer 时，注意任务脚本默认在远程 Linux 执行，本地 Windows 开发机无需运行 chmod
- Docker 部署可规避大部分问题：统一用 Linux 容器，权限在 Dockerfile 中固定（如 RUN chown -R www-data:www-data /var/www/html/storage）
