ini_set只能修改PHP_INI_USER和PHP_INI_ALL作用域的配置项，如error_reporting、date.timezone；PHP_INI_SYSTEM项（如disable_functions）不可修改。
哪些 php.ini 配置项能用 ini_set 修改
ini_set 只能修改 PHP_INI_USER 和 PHP_INI_ALL 作用域的配置项，PHP_INI_SYSTEM（如 extension_dir、disable_functions）在运行时完全不可改。查某个配置能否动态设置，最直接的方法是看官方文档里“可更改范围”一栏，或者执行：
php -r "echo ini_get('memory_limit') . PHP_EOL;"再试 ini_set('memory_limit', '256M') 看是否生效——但别只信返回值，得实际测效果。
- 常见可设项：
error_reporting、display_errors、date.timezone、memory_limit、max_execution_time - 常见不可设项：
short_open_tag、register_globals（已废弃但依然不可设）、allow_url_fopen（PHP 8.0+ 默认PHP_INI_SYSTEM） - 模块专属项（如
mysqli.default_host）通常可设，但依赖对应扩展已加载
ini_set 的生效范围和时机限制
它只影响当前请求生命周期，且必须在相关功能被调用前设置。比如想让 error_log() 写进自定义文件，得在第一次调用 error_log() 前就设好 error_log 配置项；又比如改了 date.timezone，但之前已用 date() 输出过时间，那些结果不会回滚。
- 不能在函数内“局部”覆盖：一旦
ini_set执行，整个脚本后续都受新值影响 - CLI 模式下有效，但 Web SAPI（如 Apache mod_php）中，某些配置可能被 SAPI 层拦截或重置（例如
output_buffering在 Apache 下设了也可能无效） - 如果用了 OPcache，且脚本已被缓存，
ini_set仍生效——它不走 opcode 缓存逻辑，是运行时干预
常见错误：设了但没效果？检查这三件事
最常遇到的是“明明 ini_set 返回 true，但行为没变”。不是函数失效，而是你没打中关键点。
- 拼写错误：
ini_set('display_error', '1')→ 少了个s，正确是display_errors；注意大小写，Display_Errors不行 - 类型错位：有些配置要字符串值，比如
memory_limit必须带单位（'128M'），传128 * 1024 * 1024数字会失败（返回 false） - 被后置代码覆盖：框架或 Composer 自动加载的库可能在你调用之后又执行了
ini_restore或另一次ini_set，建议在入口文件最顶部设，或用get_cfg_var()确认最终值
替代方案：什么时候该放弃 ini_set
如果你发现反复设不生效、或需要改的项根本不在允许列表里，硬扛不如换路子。特别是部署环境受限时，ini_set 往往是临时补丁，不是长期解法。
立即学习“PHP免费学习笔记（深入）”；
- 改
.htaccess（Apache）：php_value date.timezone "Asia/Shanghai"，但仅限允许 override 的虚拟主机 - 改
user.ini（PHP >= 5.3，CGI/FPM 模式）：比ini_set更稳定，按目录生效，无需改代码 - 容器或部署脚本里挂载自定义
php.ini片段，从源头控制——这才是生产环境该做的
真正难搞的从来不是语法，而是搞不清哪个配置项在哪种 SAPI 下归谁管、谁有最终解释权。多查 phpinfo() 里“Loaded Configuration File”和“Scan this dir for additional .ini files”，比死磕 ini_set 有用得多。
