CodeIgniter 3 的 helper 必须置于 application/helpers/ 下且命名格式为 xxx_helper.php；CI4 则需在 Autoload.php 注册或用 helper() 显式加载，函数须全局作用域、无命名空间，且推荐加项目前缀防冲突。
CodeIgniter 3 的 helper 文件必须放在 application/helpers/ 目录下
CI3 不支持自定义 helper 路径或子目录嵌套——哪怕你建了 application/helpers/string/ 或 application/helpers/api/，load_helper() 也找不到。它只扫描一级扁平目录，且文件名必须以 _helper.php 结尾（如 url_helper.php、mylog_helper.php）。
常见错误现象：Unable to load the requested file: helpers/my_helper.php，往往是因为路径多了一层，或者后缀写成 .php 漏了 _helper。
- 所有 helper 文件统一放
application/helpers/，别分文件夹 - 文件名格式严格为
xxx_helper.php，否则load_helper('xxx')会失败 - 加载时传入的字符串不带
_helper.php后缀，也不带路径，只写'url'、'text'
CodeIgniter 4 的 helper 可按命名空间组织，但不能用 app/Helpers/ 直接放 PHP 文件
CI4 把 helper 当作普通函数集合，靠 Composer 自动加载，所以必须通过 app/Config/Autoload.php 注册，或在控制器里用 helper() 显式引入。它不依赖固定目录结构，但也不能随便扔。
典型踩坑：把 My_helper.php 放进 app/Helpers/ 就以为能自动用——不行。CI4 不扫描该目录，也不会自动 require。
- 推荐做法：把 helper 函数写在
app/Helpers/下的xxx_helper.php文件里，然后在app/Config/Autoload.php的$helpers数组中添加'xxx' - 或者在代码里调用
helper('xxx')，CI4 会按约定去app/Helpers/找xxx_helper.php - 注意：CI4 的 helper 文件里不能有命名空间声明，函数必须是全局作用域的
跨版本混用 helper 时，is_https() 这类函数行为不一致
CI3 的 is_https() 依赖 $_SERVER['HTTPS'] 和 $_SERVER['HTTP_X_FORWARDED_PROTO']，而 CI4 的同名函数还额外检查 $_SERVER['REQUEST_SCHEME']，且默认更严格。如果你把 CI3 的 helper 复制到 CI4 下直接用，可能在反向代理环境下误判协议。
性能影响不大，但逻辑错位会导致重定向循环或混合内容警告。
- 不要直接复用旧 helper 文件，尤其涉及请求环境判断的函数
- CI4 推荐用
site_url()+ 配置$config['baseURL']的 scheme，而不是手动拼https:// - 自定义 helper 中避免硬编码
http://或https://，优先用current_url()或uri_string()补全
helper 函数名冲突比想象中更容易发生
CI3 和 CI4 都不提供 helper 函数作用域隔离——一旦两个 helper 里都定义了 limit_text()，后加载的那个会覆盖前一个，且不报错。线上突然文字截断异常，可能就因为新引入的 format_helper.php 重写了同名函数。
这问题在团队协作或引入第三方 helper 包时特别隐蔽。
- 所有自定义 helper 函数名加项目前缀，比如
myapp_limit_text()、blog_clean_title() - 加载顺序很重要：在
autoload.php里把基础 helper 放前面，业务 helper 放后面 - CI4 可用
function_exists()做防御性定义，但不如起名规范来得可靠
真正麻烦的不是目录怎么放，而是函数名没加前缀、环境判断逻辑抄来就用、还有人试图在 CI4 里模仿 CI3 的目录扫描机制——这些才是上线后半夜被叫醒的原因。
