类常量“未定义”常因同名全局常量或命名空间解析错误导致：全局define()会劫持裸常量引用；命名空间下需用完全限定名如\myapp\config\config::db_host；应禁用同名define()并用get_defined_constants()和断言快速定位冲突。
PHP里“类常量未定义”报错，很多时候不是真没定义，而是被同名的全局常量或命名空间常量覆盖、遮蔽或解析错位了。这类冲突不报语法错误，但运行时直接Fatal，尤其在引入多个组件或升级框架后高频出现。
检查类常量是否被同名全局常量劫持
如果项目中某处用 define('DB_HOST', '127.0.0.1') 定义了全局常量，又在 Config 类里写了 const DB_HOST = 'localhost';，那么在非限定调用时（如直接写 DB_HOST），PHP 会优先匹配全局常量——此时 Config::DB_HOST 虽然存在，但代码若漏写 Config:: 前缀，就会误用全局值，甚至因环境差异导致类常量“看似不存在”。
- 用
get_defined_constants(true)['user']查看当前所有用户定义常量，确认是否有意外的同名全局常量 - 搜索全项目，查
define\(.+?DB_HOST或类似模式，定位全局定义位置 - 类内访问必须显式使用
ClassName::CONSTANT，不可省略作用域前缀
验证命名空间下类常量的完整引用路径
在命名空间中（如 namespace MyApp\Config;），即使定义了 class Config { const DB_HOST = '...'; }，外部文件若未加反斜杠或未 use 导入，Config::DB_HOST 会被解析为 MyApp\Config\Config::DB_HOST，而非预期的全局 Config 类——结果就是“类未找到”，连带常量无法解析。
- 跨命名空间调用时，统一用完全限定名：
\MyApp\Config\Config::DB_HOST - 若使用
use MyApp\Config\Config;，确保该语句在命名空间声明之后、调用之前 - 避免在同一个文件中混用全局类名和同名命名空间类，例如同时存在
class Config和namespace MyApp; class Config
区分 const 定义与 define() 的作用域穿透性
const 在类中定义是严格绑定类作用域的；而 define() 创建的是全局符号表级常量，不受命名空间影响。若你在类里写 const API_TIMEOUT = 30;，又在配置文件中 define('API_TIMEOUT', 15);，两者互不干扰——但一旦代码中漏掉 MyClass:: 直接写 API_TIMEOUT，就只会取到 define() 的那个，且 IDE 和静态分析可能误判类常量“未被使用”。
- 项目中统一约定：配置类全部用
const，运行时动态值用$_ENV或配置数组，禁用同名define() - 用 PHPStan 或 Psalm 开启
checkConstantNameCase和checkClassConstantUsage规则，提前捕获裸常量引用 - 在入口文件顶部加断言：
assert(defined('MyApp\Config\Config::DB_HOST') === false, 'Avoid global constant shadowing');
快速定位冲突点的调试技巧
不用逐行翻代码，三步锁定问题源头：
- 在报错行上方加：
var_dump(class_exists('Config'), defined('Config::DB_HOST'), get_class_vars('Config') ?? []); - 执行
php -r "print_r(array_keys(get_defined_constants(true)['user']));"，筛出疑似冲突的常量名 - 临时注释掉所有
define()调用，只留类定义，看报错是否消失——若消失，基本确定是全局常量干扰
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
