define()定义的常量天然全局可见，不受函数、类或命名空间作用域限制，可在任意位置直接使用；而const受命名空间和类作用域约束，且必须在编译期声明。
define() 定义的常量天然全局可见，根本不需要“跨函数访问”——它在任何函数、方法、作用域内都能直接用。
为什么 define() 定义的常量能直接在函数里用
因为 define() 创建的是**全局常量**，不属于任何变量作用域。PHP 的常量作用域模型和变量完全不同：它不随函数调用栈变化，也不受 global 或 static 修饰影响。
常见误解是把它当成变量去“传递”或“引入”，结果写一堆 global CONST_NAME 或试图 use ——这些全没必要，也无效。
-
define("API_TIMEOUT", 30)后，在function fetchApi()里直接写curl_setopt($ch, CURLOPT_TIMEOUT, API_TIMEOUT)即可 - 哪怕嵌套多层匿名函数、闭包、回调，只要没重名覆盖，
API_TIMEOUT都能原样访问 - 类方法内部也能直接用：
public function connect() { return $this->timeout = API_TIMEOUT; }
define() 和 const 在作用域上的关键区别
很多人混淆 define() 和顶层 const，以为它们行为一致。其实核心差异在“定义时机”和“命名空间感知”：
立即学习“PHP免费学习笔记（深入）”；
-
define("DB_HOST", "localhost")：运行时执行，**无视命名空间**，总注册到全局空间（即DB_HOST），无论你在namespace AppConfig;里调用它 -
const DB_HOST = "localhost";（顶层）：编译时解析，**受当前命名空间影响**，实际定义为AppConfigDB_HOST，除非显式写const DB_HOST = ... - 所以如果你在命名空间文件里用
define()，然后在另一个命名空间里直接写DB_HOST——没问题；但用const DB_HOST，就得写DB_HOST或AppConfigDB_HOST才能访问
容易踩的坑：defined() 检查时路径写错
用 defined() 判断常量是否存在时，传入的字符串必须和定义时的**完整名称完全一致**。尤其注意命名空间场景：
- ✅ 正确：
define("LOG_LEVEL", "info");→defined("LOG_LEVEL")返回true - ❌ 错误：
const LOG_LEVEL = "info";（在namespace App;下）→defined("LOG_LEVEL")返回false，必须写defined("App\LOG_LEVEL")或defined("App::LOG_LEVEL")（后者仅适用于类常量） - ⚠️ 特别注意反斜杠转义：在双引号字符串中，
"AppLOG_LEVEL"会被解释为App<lf>OG_LEVEL</lf>（L是换行符），应写成"App\LOG_LEVEL"或单引号'AppLOG_LEVEL'
什么时候不该用 define() 做“跨函数共享”
虽然 define() 确实能跨函数访问，但它不是设计来替代配置传递或依赖注入的。以下情况建议换方案：
- 需要类型安全：比如希望
MAX_RETRY必须是int，define()不支持类型声明，改用const int MAX_RETRY = 3; - 值来自环境或运行时计算：如
define("APP_ENV", $_ENV['APP_ENV'] ?? 'dev')可行，但更推荐用配置对象或 DI 容器管理，避免污染全局常量空间 - 要限制访问范围：比如某个常量只该被某几个类使用，
define()全局暴露会破坏封装，此时应改用类常量 +private或protected修饰符（PHP 8.1+） - 定义数组或对象常量：PHP 7.0+ 支持
define("ROUTES", [...])，但 PHP 8.0+ 推荐用const ROUTES = [...]（更高效，且支持表达式）
真正需要 define() 的场景，通常是动态生成常量名（如插件系统加载时拼接）、条件定义（if (!defined('DEBUG')) define('DEBUG', true);），或者兼容老代码。
