model类无法直接调用application/common.php中的全局函数，因其运行在独立作用域且不自动加载该文件；解决方案有三：改造成工具类静态方法、模型中手动require_once、或在config/app.php配置load_ext_file。
Model 类里不能直接使用 application/common.php 中定义的全局函数，因为模型默认不加载该文件，且 TP5 的模型运行在独立作用域中——这是最常被忽略的前提。
为什么在 Model 里调用自定义函数会报错“function not found”
TP5 的 Model 类（如继承 \think\Model）本身不自动包含 common.php；即使你在控制器里能正常调用，在模型中直接写 getModelFieldType(2) 也会提示未定义函数。这不是路径或命名空间问题，而是加载时机问题：框架只在应用初始化阶段（如请求入口、控制器实例化前）自动载入 common.php，而模型可能在后期动态实例化，此时函数尚未声明。
常见错误现象：
Call to undefined function getModelFieldType()- 函数在控制器里可用，一挪到
model/xxx.php就失效 - 用
use function或global也无效——PHP 不支持跨文件作用域导入函数名
三种可行方案及适用场景
必须明确：没有“最佳”，只有“合适”。选哪种取决于你调用函数的目的和频率。
-
方案一（推荐用于简单转换逻辑）：把函数改造成静态方法，放进一个工具类（如
app\common\tool\Format.php）
例如：namespace app\common\tool; <p>class Format { public static function getModelFieldType($type) { $arr = ["1" => '单行文本', "2" => '单选按钮', /<em> ... </em>/]; return $arr[$type] ?? '未知类型'; } }</p>然后在模型中调用：app\common\tool\Format::getModelFieldType($this->type)。优势是可复用、可测试、不依赖全局作用域。 -
方案二（仅限少量、纯数据处理函数）：在模型构造函数或初始化方法里手动
require_once
在模型类顶部加：protected function initialize() { require_once APP_PATH . 'common.php'; parent::initialize(); }⚠️注意：APP_PATH指向application/目录，确保路径正确；且该方式无法在静态方法（如where()->select()链式调用中）安全使用。 -
方案三（适合已有大量全局函数且不想重构）：在
config/app.php中配置自动加载
添加配置项：'load_ext_file' => 'common',
该配置会让框架在每次请求开始时自动加载application/common.php，从而保证所有上下文（包括模型）都能访问其中函数。但要注意：若common.php中有副作用代码（如执行 SQL、修改全局变量），可能引发并发或重复执行问题。
模板中通过模型属性间接调用的陷阱
有人尝试在模型里定义一个获取器（accessor），比如：
public function getTypeTextAttr($value, $data)
{
return getModelFieldType($data['type']); // ❌ 这里会报错
}这看似合理，但实际仍会失败——因为获取器执行时，common.php 并未被当前作用域加载。解决办法只有上面三种之一，最稳妥的是改用静态工具类：return \app\common\tool\Format::getModelFieldType($data['type']);。另外注意：TP5 模板中不能直接写 {$user.typeText} 调用获取器返回值，必须确保该属性已在模型中被显式赋值或通过 withAttr 映射，否则会静默输出空字符串。
别忘了 autoload 和命名空间的边界
如果你把自定义函数放进 extend/ 目录（如 extend/helper/field.php），需手动注册自动加载，或在模型中用 include 加载。但更推荐统一走 PSR-4 命名空间方式——毕竟 extend/ 下的函数默认在全局命名空间，容易与第三方库冲突。真正需要复用的逻辑，应封装为类而非裸函数。
