PHP数据沙箱本质是通过环境变量（如APP_ENV）驱动配置加载与功能开关，确保同一套代码在不同环境连接不同数据库、读取不同密钥；关键在于环境变量可信、配置不被覆盖、敏感信息不外泄，而非物理隔离。
PHP 实现数据沙箱，本质不是建一个“虚拟机”，而是通过配置、加载逻辑和运行时判断，让同一套代码在不同环境里连接不同的数据库、读取不同的密钥、跳过或启用特定功能。关键不在于“有没有沙箱”，而在于“环境变量是否可信、配置是否被覆盖、敏感信息是否外泄”。
APP_ENV 和 .env 文件必须严格配合
很多项目只设 APP_ENV=local，却没在 .env 里同步控制数据库配置开关，结果开发环境连上了生产库。Laravel 默认靠 APP_ENV 决定是否加载 .env，但原生 PHP 项目得自己写逻辑——比如用 getenv('APP_ENV') 判断后，再 require 对应的 config/database_{$env}.php。
-
APP_ENV必须由 Web 服务器（如 Nginx/Apache）或 CLI 启动时注入，不能靠putenv()在 PHP 里硬写，否则容易被覆盖 -
.env文件不能提交到 Git，且需在public/外，避免被直接访问；用$_ENV读取前要确认variables_order包含E - 如果用
vlucas/phpdotenv，注意它默认不覆盖已存在的环境变量，overload => true才能确保.env优先生效
数据库配置不能靠 if-else 硬编码拼接
常见错误是写成：if (APP_ENV === 'prod') { $host = 'db-prod'; } else { $host = 'localhost'; }。这种写法看似清晰，实则把环境逻辑散落在各处，后期加测试环境或灰度环境时极易漏改。
- 推荐做法：所有数据库参数统一从一个函数返回，例如
getDatabaseConfig()，内部根据APP_ENV查表或加载文件 - 配置数组必须包含完整字段（
host、port、dbname、username、password），缺失字段要抛异常，而不是静默 fallback - 生产环境密码绝不能出现在代码中，必须走系统环境变量（如
DB_PASSWORD）或密钥管理服务，.env仅用于本地开发
沙箱 ≠ 完全隔离，危险函数仍可执行
很多人以为用了 Docker 或 PRoot 就“进了沙箱”，其实 PHP 进程只要没禁用 exec、shell_exec、system，就仍可能调用宿主机命令。尤其当应用解析用户上传的模板或配置时，风险极高。
立即学习“PHP免费学习笔记（深入）”；
- 检查
disable_functions配置，至少禁用exec,shell_exec,system,passthru,proc_open - 数据库连接若用
mysqli或PDO，确保未开启mysql.allow_local_infile，防止利用 LOAD DATA INFILE 读取任意文件 - 离线测试时，可用
sqlite://:memory:替代 MySQL，避免依赖外部服务，也天然阻断跨库操作
Debugbar、日志、错误报告必须按环境开关
开发环境开着 DEBUGBAR_ENABLED=true 没问题，但一旦 APP_DEBUG=false，debugbar 的中间件、收集器、前端 JS 脚本都必须彻底不加载——否则可能泄露路由、SQL、会话结构等敏感信息。
- 不要只关配置项，还要确认服务提供者（Service Provider）是否注册，例如 Laravel 中
Barryvdh\Debugbar\ServiceProvider应只在APP_DEBUG=true时注册 - 错误页面（Whoops / Symfony Error Page）在生产环境必须关闭，改用
error_log()记录，且日志路径不能是 Web 可访问目录 - 测试环境建议启用慢查询日志（
slow_query_log=ON），但日志路径要独立，且定期清理，避免磁盘打满
最常被忽略的一点：环境变量的优先级链。Apache 的 SetEnv、Nginx 的 fastcgi_param、Shell 的 export、.env、php.ini 的 variables_order —— 这些层层叠加，稍有错位就会导致 APP_ENV 读错，整个隔离逻辑崩塌。上线前务必用 var_dump($_SERVER['APP_ENV'] ?? null, $_ENV['APP_ENV'] ?? null) 实测确认。
