真实应用，端到端验证

ENTRY_FILE=index.php 会选择框架模式：public/ 成为文档根目录，因此 .env、app/ 和 vendor/ 永远无法通过 HTTP 访问。

容器环境变量会覆盖 .env——Laravel 的 dotenv 加载器绝不会覆盖真实的环境变量，因此在 Compose 中设置的 DB_HOST 和 APP_ENV 会生效。

开发镜像会在每个请求上重新校验 OPcache；对绑定挂载的 src/ 所做的修改会立即生效。

该骨架仅凭核心扩展就能运行（ctype、iconv、xml）；之所以额外加入原生的 intl 和 mbstring，是因为真实应用会用到它们，而且它们比 polyfill 更快。

APP_ENV 来自容器环境——Symfony 会优先读取真实的环境变量而非 .env。

静态资源会解析为 public/ 中的真实文件并从磁盘提供，只有未命中时才回退到 index.php。

无数据库，无额外服务——尽可能小的 OxPHP 部署：一个镜像，一个进程。

yiisoft/assets 会把静态文件发布到 public/assets/<hash>/——磁盘上的真实文件，无需折腾 URL 重写。

传统模式是必需的：wp-admin/、wp-login.php 和 wp-cron.php 必须作为物理文件执行——ENTRY_FILE 保持未设置。

PHP_DENY_PATHS 会阻止在 wp-content/uploads/ 下执行 .php——通过存在漏洞的插件上传的 shell 永远不会运行；匹配发生在磁盘 I/O 之前，不会泄露文件是否存在。

CLI 相关的工作通过一个 WP-CLI 边车容器完成，它共享同一个卷和数据库；wp-config.php 通过 getenv() 读取凭据。

Drupal 的 RewriteCond !-f + RewriteRule ^ index.php 正好就是框架模式：提供已存在的文件，其余全部分发给 web/index.php。

web/sites/default/files/ 下聚合后的 CSS/JS 会作为静态文件从磁盘提供。

冷启动的首个请求会预热 Twig 和各类缓存（约 15 秒）；此后响应只需个位数毫秒——这是 Drupal 的预热开销，而非 OxPHP 的开销。

控制面板资源（web/cpresources/<hash>/）是磁盘上的真实文件，由框架模式提供。

使用 MySQL 8.4 LTS，而非 9——Craft 是针对 8.x 验证过的。

数据库设置来自容器环境（CRAFT_DB_*），因此它们放在 Compose 中。

october:mirror public 复现了 October 的 nginx 资源白名单：public/ 只保留 index.php 和 */assets 符号链接；主题、config/、.env 和 vendor/ 都留在 web 根目录之外。

SYMLINK_ALLOW_PATHS=/var/www/html 是必需的——镜像的符号链接会指回项目目录树，而 OxPHP 默认会阻止这一点。

别忘了 tailor:migrate：演示主题的 Tailor 蓝图会独立于 october:migrate 单独创建自己的表。

带版本号的静态 URL（/static/version<N>/…）需要在 pub/static 内建立一个自引用符号链接——nginx 会用重写规则去掉那一段路径，而 OxPHP 不做重写。

请以生产模式运行：开发者模式会在请求时生成 DI 类，可能在多线程工作进程池中引发竞态。

MySQL 需要 --log_bin_trust_function_creators=1；composer install 通过构建好的 PHP 8.4 镜像运行，而非现成的 composer:2。

两个物理的前端控制器——index.php 和 admin/index.php——所以采用传统模式；框架模式会把后台请求汇集到店面控制器。

web 根目录就是项目根目录，因此 PHP_DENY_PATHS=/system/**,/install/** 会阻止直接执行内部文件；点文件默认已经返回 404。

默认的查询路由（index.php?route=…）无需任何重写规则即可工作。