CI4服务容器本身跨平台一致，差异源于Windows/Linux对Docker、文件路径、权限及网络栈的处理不同，影响自动加载、数据库连接、日志写入和会话初始化等依赖底层环境的服务行为。
CI4（CodeIgniter 4）服务容器本身是 PHP 层的依赖注入容器，跨平台行为一致；真正产生差异的是它所运行的底层环境——即 Windows 和 Linux 对 Docker、文件路径、权限、进程模型的处理方式。这些差异不会改变 Services 类的用法，但会直接影响容器注册、服务实例化、自动加载和调试体验。
Windows 下 Services::autoloader() 加载失败或缓存不生效
CI4 的自动加载器依赖于 PHP 的 opcache 和文件系统一致性。Windows 默认使用 NTFS，而 Docker Desktop 在 WSL2 模式下通过 9P 协议挂载主机目录，导致 opcache 缓存键计算不稳定，尤其在启用 opcache.validate_timestamps=1 时容易漏刷新。
- 现象：修改
App\Services\MyService.php后，Services::myService()仍返回旧实例，或抛出Class not found - 解决：在
php.ini中强制禁用 opcache 文件校验（仅开发环境）：opcache.validate_timestamps=0，并配合opcache.revalidate_path=1 - 更稳妥做法：把
app/目录从挂载卷中移出，改用 COPY 构建进镜像（Linux 环境下无需此操作）
Linux 容器里 Services::database() 连接超时，Windows 本地却正常
这不是 CI4 容器的问题，而是网络栈抽象层差异导致的 DNS 或 host 解析行为不同。Linux 容器默认使用宿主机的 /etc/resolv.conf，而 Windows 上 Docker Desktop 使用内置 DNS（如 10.0.75.1），且对 host.docker.internal 的解析有延迟或失败。
- 典型表现：在
Database配置中使用hostname => 'db'（docker-compose service 名）时，Linux 容器能立即解析，Windows 下需数秒甚至超时 - 临时修复：在
docker-compose.yml中为 CI4 服务显式指定 DNS：dns: ['8.8.8.8', '1.1.1.1'] - 根本方案：避免依赖 DNS 解析，改用静态 IP（如
172.18.0.2）或在/etc/hosts中预埋映射（需通过extra_hosts注入）
Services::logger() 在 Windows 挂载卷下写日志失败
CI4 默认日志路径为 WRITEPATH . 'logs/'，而 Windows 用户常将项目目录挂载为 -v C:\myapp:/var/www/html。问题在于：NTFS 权限未映射到 Linux UID/GID，导致容器内 www-data 用户无权写入该路径。
- 错误信息：
Failed to open stream: Permission denied in Logger.php - 不要在
docker run中加--user root（破坏最小权限原则） - 正确做法：在 Dockerfile 中提前创建日志目录并赋权：
RUN mkdir -p /var/www/html/writable/logs && chown -R www-data:www-data /var/www/html/writable - 或改用非挂载路径存储日志（如
/tmp/logs），再通过tail -f查看
Linux 容器启动快但 Windows 下 Services::session() 初始化卡顿
Session 驱动若设为 file，CI4 会尝试在 SESSIONPATH 创建/锁定文件。Windows 主机挂载卷在 WSL2 下存在 fcntl 锁竞争问题，导致 session_start() 阻塞数秒。
- 验证方式：把
session.driver改为database或redis，卡顿立即消失 - 不推荐改用
cache驱动（无持久性，不适合生产） - 折中方案：保留
file驱动，但将SESSIONPATH指向容器内路径（如/tmp/sessions），而非挂载卷
最易被忽略的点是：CI4 的容器行为本身没有平台差异，但所有依赖文件 I/O、进程间通信、网络解析的服务——比如日志、缓存、数据库、会话——都会因底层 OS 抽象层不同而表现出不一致。别急着改 CI4 配置，先确认你正在调试的是应用逻辑，还是 Docker + Windows 的组合副作用。
