助手函数报错主因是路径错误或重复定义：必须将函数定义在app/helper.php且在composer.json autoload中声明，改后运行composer dump-autoload；重复定义需全局搜索并用function_exists包裹；Db门面报错因Session/Config未初始化，应避免在中间件前调用。
助手函数报错，八成是加载路径或重复定义问题，不是函数写错了。
助手函数找不到：Call to undefined function my_helper_func()
ThinkPHP 6 不再自动扫描任意 helper.php 文件。它只认一个固定位置：app/helper.php —— 注意是 app/ 目录下，不是 app/common/、app/extend/ 或 public/ 里。
必须确保两件事同时成立：
-
app/helper.php文件真实存在，且函数定义在该文件中（不要用require引入其他 helper 文件） -
composer.json的"autoload": {"files": []}里明确写了"app/helper.php"，改完后必须运行composer dump-autoload - 如果项目曾删过
composer.json中的 autoload 配置，或手动加过require APP_PATH.'helper.php'，就会导致加载失败或冲突
助手函数重复定义：Fatal error: Cannot redeclare function
全局搜索你的函数名（比如 my_format_date），看是否在多个地方被定义。常见雷区：
立即学习“PHP免费学习笔记（深入）”；
-
config/app.php中配置了'extra_file' => [APP_PATH.'common.php']，而common.php又require了helper.php - 你在命令行脚本里手动
require __DIR__.'/app/helper.php'，但框架启动时 Composer 已经加载过一遍 - 执行过
composer dump-autoload -o把helper.php打包进 classmap，TP 再走自己的 Loader 就会二次加载 - 所有
include/require务必换成include_once/require_once，尤其在config/、public/下的手动引入
助手函数里调用 Db::table() 报 Call to a member function set() on null
这不是 Db 门面本身坏了，而是 Session 或 Config 没初始化到位。助手函数在中间件之前就可能被执行，此时 Db 门面底层依赖的容器实例还没准备好。
典型触发场景是 token 校验类助手函数，在路由解析前就调用了 Db::table()。
- 检查
app/middleware.php是否已启用think\middleware\SessionInit（单应用模式） - 多应用模式下，需在对应应用目录（如
app/api/middleware.php）中单独配置该中间件 - 更稳妥的做法：把涉及门面的操作移到控制器或服务类中，助手函数只做纯逻辑、无依赖的计算（如格式化、字符串处理）
- 若必须用 Db，可加一层判空：
if (is_null(\think\Db::connect())) { \think\App::initialize(); }，但不推荐——这绕过了框架生命周期
多应用模式下助手函数行为异常
ThinkPHP 6 的 app/helper.php 是全局共用的，不存在「每个应用一份」的概念。如果你在不同应用里定义同名函数，或通过条件判断动态定义函数，很容易踩到 Cannot redeclare。
建议做法：
- 所有助手函数统一放在
app/helper.php，用function_exists()包裹定义，例如：if (!function_exists('api_token_check')) { function api_token_check() { ... } } - 避免在助手函数里直接读取应用专属配置（如
config('api.token_expire')），改用参数传入 - 如果真需要按应用隔离逻辑，不要用助手函数，改用服务类 + 依赖注入，由容器按应用绑定不同实现
最常被忽略的一点：助手函数一旦加载，就永远在全局作用域里。哪怕你只在某个接口里用了一次，它也会对整个请求生命周期生效——包括后续的中间件、钩子、甚至日志写入。所以别在里面做状态缓存、静态变量计数之类的事。
