composer仅支持通过autoload.files加载全局函数文件，需在composer.json的autoload对象下配置files数组，路径相对项目根目录，修改后须运行composer dump-autoload生效，且文件仅允许定义函数、常量等无副作用逻辑。
Composer 本身不支持直接加载函数
Composer 是 PHP 的依赖管理工具，它只负责安装包、生成自动加载器（autoload），并不提供“按需加载独立函数”的机制。所谓“通过 Composer 加载函数”，本质是把函数定义放进某个可被自动加载的上下文中——最常见且唯一可靠的方式是：把函数写在 autoload.files 配置指定的 PHP 文件里，由 Composer 在初始化时 require 进来。
用 autoload.files 注册全局函数文件
这是实际项目中最常用、也最稳妥的做法。你需要在 composer.json 中声明一个或多个 PHP 文件，这些文件会在每次 composer dump-autoload 后被写入自动加载逻辑，并在 vendor/autoload.php 被引入时立即执行（即函数注册进全局作用域）。
实操建议：
- 把所有工具函数集中放在一个文件里，比如
src/Functions.php，文件内直接写function my_helper() { ... }，不要包裹在命名空间或类中 - 在
composer.json的autoload段添加："autoload": { "files": ["src/Functions.php"] } - 运行
composer dump-autoload—— 此时vendor/autoload.php已包含对该文件的require - 只要项目中引入了
vendor/autoload.php（绝大多数框架和脚本都这么做），函数就可用
注意：修改 autoload.files 后必须重新生成自动加载器，否则函数不会生效；该方式加载的函数是全局的，无法按需延迟加载，适合稳定、高频使用的辅助函数。
为什么不用 autoload.functions 或其他变通方式
PHP 没有 autoload.functions 这个配置项，那是常见误解。有人尝试用 PSR-4 + 函数名命名空间模拟，但无效——PHP 函数不属于类，不参与类自动加载流程。还有人想用 include_once 手动加载、或借助插件钩子，这些都绕开了 Composer 的标准机制，导致部署不一致、CI 失败、IDE 无法识别等问题。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
容易踩的坑：
- 把函数文件放在
vendor/下并试图用autoload.files引用——Composer 不会跟踪vendor/内部的自定义路径，且下次composer update可能覆盖 - 函数文件里用了
declare(strict_types=1)或namespace—— 会导致语法错误或函数无法注册到全局作用域 - 多个
autoload.files条目之间存在函数重定义，而 Composer 不做冲突检测，运行时报Fatal error: Cannot redeclare xxx()
函数包发布时的 autoload 配置要点
如果你是把函数打包成独立包（如 myorg/helpers）供他人使用，composer.json 中仍需明确声明 autoload.files，且路径应相对于包根目录（通常为 functions.php 或 src/functions.php）。使用者只需 require 你的包，无需额外配置即可使用函数。
关键细节：
- 包的
autoload.files路径必须是相对路径，不能以/开头，也不能含.. - 建议在包文档里明确写出“该包提供全局函数，已通过
autoload.files注册”，避免使用者误以为要手动require - 若函数内部依赖其他类（比如
MyHelper::doSomething()），确保对应类已通过 PSR-4 正确声明，否则运行时抛出Class not found
函数不是类，没有实例化开销，但也没有自动加载的粒度控制——一旦引入，全量加载。真正需要按需加载的场景，更适合封装成无状态的静态类方法或单例服务。
