不能将config.php放在/public或/htdocs下，否则服务器配置异常时会直接暴露数据库密码；正确做法是将其置于Web根目录外（如/config/），由public/index.php通过相对路径加载，并配合服务器deny规则和环境变量替代。
直接把 config.php 放进 /public 或 /htdocs 就是最大风险点——只要 Web 服务器配置稍有偏差（比如 PHP 模块崩溃、后缀未被解析），用户访问 /config.php 就会原样输出数据库账号密码。这不是“可能”，而是真实发生过上百次的泄露根源。
为什么不能让配置文件在 Web 可访问路径下
Web 根目录（如 Apache 的 DocumentRoot 或 Nginx 的 root）里的所有文件，默认都可能被 HTTP 直接请求。哪怕你没主动链接它，攻击者也能用扫描器批量探测：/config.php、/database.php、/settings.inc……一旦匹配到常见命名，且服务器没正确解析 PHP，就直接返回明文。
更隐蔽的风险是：开发时临时加的 phpinfo()、print_r($config) 或调试注释，也会随配置文件一起暴露。
正确的目录结构与加载方式
必须把代码和 Web 入口物理隔离：
立即学习“PHP免费学习笔记（深入）”；
- 应用根目录设为
/var/www/myapp/（不可通过 URL 访问） - Web 入口仅保留
/var/www/myapp/public/，并将其设为服务器的DocumentRoot - 把
config.php放在/var/www/myapp/config/或/var/www/myapp/app/这类上层目录中 - 在
public/index.php中用绝对路径或相对上级路径包含：require __DIR__ . '/../config/config.php';
注意：__DIR__ 是当前文件所在目录，public/index.php 执行时能读取上级目录，但浏览器无法跨出 public/ 去请求它——这是操作系统权限 + Web 服务器路径限制双重保障。
Apache 和 Nginx 必须补的兜底规则
即使目录结构正确，也不能依赖“没人会猜路径”。必须显式禁止对敏感扩展名的访问：
- Apache（写在
.htaccess或虚拟主机配置里）：<FilesMatch "\.(env|ini|dist|bak|log|sql|yml|yaml|xml|json|conf|cfg|inc)$">Order Allow,Deny</FilesMatch> - Nginx（写在
server块内）：location ~ \.(env|ini|dist|bak|log|sql|yml|yaml|xml|json|conf|cfg|inc)$ { deny all; }
特别注意：.inc 文件常被误认为“只是包含文件”，但若未被 PHP 解析，就会以纯文本返回——很多老项目仍沿用 db.inc 命名，必须拦住。
环境变量替代法（适合 Docker / 云部署）
当连 config.php 都不想落地时，用环境变量加载最干净：
- 删掉所有硬编码的
$host = 'localhost';，改用：$host = $_ENV['DB_HOST'] ?? getenv('DB_HOST'); - Docker 启动时传入：
-e DB_HOST=10.0.1.5 -e DB_PASSWORD=xxx - 或用
.env文件（确保该文件被上面的deny all规则拦截，且不提交到 Git）
这种做法绕过了文件读取环节，也规避了「配置文件权限设错」的问题——但要注意，getenv() 在某些 PHP-FPM 模式下默认禁用，需检查 variables_order 是否含 E。
最容易被忽略的一点：config.php 自身如果用了 die() 或 exit() 防止直接访问，是无效的——因为它是被 require 进来的，不是独立执行入口；真正起作用的，只有路径隔离 + Web 服务器拒绝规则 + 系统文件权限三者叠加。
