phpEnv中assert不触发是因为zend.assertions=-1彻底移除断言代码，assert.active无效；必须设zend.assertions=1且assert.exception=1，并重启环境。
phpEnv 下不能靠改 php.ini 里的 assert.active 来开启断言——它会被 zend.assertions 覆盖，且 phpEnv 默认设为 -1，此时 assert() 完全不编译、不执行，改 assert.active 没用。
为什么改了 assert.active = On 还是不触发断言
phpEnv 使用的是 PHP 的「编译期断言开关」机制：zend.assertions 才是决定 assert 代码是否进入 AST 的第一道闸门。它的三个取值含义明确：
-
zend.assertions = 1：断言被编译 + 执行（开发环境唯一可用模式） -
zend.assertions = 0：断言被编译但跳过执行（极少用，性能无优势） -
zend.assertions = -1：断言语句直接从字节码中剔除（phpEnv 默认，生产安全首选）
你在 php.ini 里把 assert.active = On 改得再勤，只要 zend.assertions = -1，assert('$x > 0') 这行代码在运行前就被 PHP 编译器“当空气删掉了”，根本不会走到执行阶段。
在 phpEnv 中正确启用断言的两步操作
必须同时满足以下两个条件，断言才会真正生效：
立即学习“PHP免费学习笔记（深入）”；
- 确认当前使用的 PHP 版本配置文件路径：
php --ini查出 Loaded Configuration File，别改错 ini 文件（phpEnv 可能有多个版本共存） - 在对应 php.ini 中修改两处（缺一不可）：
zend.assertions = 1assert.exception = 1（推荐，让失败抛AssertionError而非警告） - 重启 Web 服务或 CLI 环境：phpEnv 下如果是 Apache/Nginx，需 reload；如果是 CLI 测试，关掉当前终端重开，否则旧配置仍缓存
- 验证是否生效：
php -r "var_dump(ini_get('zend.assertions'), ini_get('assert.active'));"应输出string(1) "1" string(1) "1"
assert_options() 在 phpEnv 中的局限性
运行时调用 assert_options(ASSERT_ACTIVE, 1) 或 ini_set('assert.active', '1') 是无效的——前提是 zend.assertions = -1。因为 PHP 已经不把 assert 当作有效语句解析了，函数调用本身都不存在。只有 zend.assertions = 1 时，这些运行时设置才起作用。
常见误操作：
- 只改
assert.active，没动zend.assertions→ 断言静默失效 - 改了 php.ini 却忘记重启服务或新开终端 → 配置未加载
- 在 CLI 下用
php -d zend.assertions=1 -d assert.exception=1 script.php临时启用，但误以为这能影响 Web 环境 → CLI 和 Web 的 PHP 配置完全独立
开发与生产环境的配置差异必须硬隔离
phpEnv 常用于本地多版本切换，但一个疏忽就可能把开发配置带到线上：
- 开发机上：确保每个 PHP 版本的 php.ini 都设为
zend.assertions = 1，并配合assert.exception = 1方便捕获 - 上线前检查：CI/CD 构建阶段应强制注入
zend.assertions = -1（可通过 Dockerfile 或部署脚本覆盖） - 绝不依赖运行时开关：不要指望用
ini_set()在入口文件里“动态开启断言”来绕过编译限制——它不起作用
最易被忽略的一点：phpEnv 的「全局默认配置」往往指向一个通用 php.ini，而你实际项目用的可能是通过 phpenv local 8.2 切换的版本，其 php.ini 路径完全不同。务必对每个 active 版本单独确认配置。
