执行LOAD DATA INFILE时若报“Permission denied”或“open_basedir restriction”，主因是PHP层open_basedir限制了文件路径；需确保目标路径（如/tmp/）明确列入open_basedir白名单，且配置后重载PHP-FPM/Apache/Nginx。
Load Data Infile 被 open_basedir 拦住的典型报错
执行 LOAD DATA INFILE 时抛出类似 Can't get stat of '/tmp/data.csv' (Errcode: 13 - Permission denied) 或 open_basedir restriction in effect，基本可以断定是 open_basedir 在起作用——哪怕你没在 SQL 里写绝对路径，MySQL 的 LOAD DATA INFILE 实际仍会通过 PHP 的文件系统接口访问本地文件，而该操作受 PHP 层面的 open_basedir 约束。
为什么 open_basedir 会干预 MySQL 的 LOAD DATA INFILE
PHP 的 PDO/MySQLi 驱动在执行 LOAD DATA INFILE 时，底层仍需调用 fopen()、stat() 等系统调用读取本地文件。这些函数全部受 open_basedir 限制，与是否走 MySQL 协议无关。
-
LOAD DATA LOCAL INFILE（带 LOCAL）才真正由 PHP 客户端读取文件并发送给 MySQL；它必然触发 PHP 文件操作，open_basedir必检 -
LOAD DATA INFILE（无 LOCAL）理论上由 MySQL 服务端直接读，但某些 PHP 配置或驱动版本（尤其旧版 MySQLi）仍会先校验路径合法性，导致误拦 - 即使 MySQL 配置了
local_infile=ON，PHP 层的open_basedir不放行对应路径，照样失败
如何快速验证和修复路径白名单
重点不是“能不能用”，而是“文件路径是否落在 open_basedir 允许范围内”。注意：路径必须以 / 结尾才能精确匹配目录边界，否则 /tmp 会意外允许 /tmp2024/。
- 查当前生效值：
php -r "echo ini_get('open_basedir');"（CLI）或phpinfo()（Web） - 确认你要加载的文件所在路径，比如
/tmp/import.csv，那么open_basedir至少得包含/tmp/ - 多个路径用冒号分隔（Linux/macOS）：
open_basedir = "/var/www/html/:/tmp/:/home/user/uploads/" - 若用 Apache +
php_admin_value，确保配置在正确的<VirtualHost>或<Directory>块内，且重启服务 - Nginx 用户注意：
fastcgi_param PHP_VALUE "open_basedir=/var/www/html/:/tmp/";必须放在location ~ \.php$块中，且不能被后续同名参数覆盖
绕过限制的现实选择与风险提示
别指望用 symlink() 或 chdir() 绕过——open_basedir 检查的是真实路径（realpath），软链目标不在白名单内照样报错。唯一合法出口是加路径，但要注意：
立即学习“PHP免费学习笔记（深入）”；
- Web 环境下把
/tmp加进open_basedir是常见做法，但务必确保上传/临时文件逻辑不暴露可写入口 - CLI 环境（如定时任务跑 import）建议单独配宽松的
open_basedir，避免和 Web 配置混用 - 如果业务允许，改用
LOAD DATA LOCAL INFILE+mysqli_options($link, MYSQLI_OPT_LOCAL_INFILE, true)，再确保对应路径在白名单里——这是最可控的方式 - 真正麻烦的是 MySQL 服务端直读场景：此时 PHP 层虽不读文件，但部分驱动仍做预检；遇到这种，只能升级驱动或换用
PDO::MYSQL_ATTR_LOCAL_INFILE => true显式启用客户端模式
最易被忽略的一点：修改 open_basedir 后，PHP-FPM 需要 reload（不是 restart），Apache 需要 graceful restart，Nginx 需要 reload——只改配置不重载，等于没改。
