phpEnv不提供include_path配置入口，需修改对应PHP版本的php.ini文件；CLI与Web环境可能使用不同php.ini，须分别确认并设置include_path。
phpEnv 本身不提供 include_path 的独立配置入口，它只是 PHP 版本管理工具；真正起作用的是你当前激活的 PHP 实例自身的配置 —— 所以你要改的不是 phpEnv，而是对应 PHP 版本的 php.ini 或运行时逻辑。
phpEnv 下如何定位并修改真实生效的 php.ini
phpEnv 切换版本后，php --ini 显示的 Loaded Configuration File 才是实际被读取的文件。常见路径有：
-
/home/username/.phpenv/versions/{version}/etc/php.ini（Linux/macOS 用户目录下） -
C:\Users\{user}\.phpenv\versions\{version}\etc\php.ini（Windows）
别直接改全局系统级的 /etc/php/*/cli/php.ini，那和 phpEnv 管理的实例无关。确认路径后，搜索 include_path 行，取消注释并设置，例如：
include_path = ".:/home/username/mylibs:/home/username/vendor"
注意：多个路径用 PATH_SEPARATOR 分隔（Linux/macOS 是 :，Windows 是 ;），但写死在 php.ini 里必须匹配当前系统。
立即学习“PHP免费学习笔记（深入）”；
为什么 set_include_path() 在 phpEnv 环境中常失效
因为很多框架或 Composer 项目会主动重置 include_path，尤其是 CLI 模式下执行脚本时 —— 它可能在你调用 set_include_path() 前就被框架初始化逻辑覆盖了。
- 检查是否在
index.php或入口文件顶部就调用了set_include_path()，且没被后续代码覆盖 - 用
echo get_include_path();在关键位置输出，确认值是否如预期 - 若用 Composer，
vendor/autoload.php默认不依赖include_path，它走的是绝对路径 +require，所以改include_path对 Composer 加载无影响
第三方库该不该靠 include_path 加载
现代 PHP 项目基本不该依赖 include_path 加载第三方库，原因很实际：
-
require_once 'SomeClass.php'在include_path中查找时，不支持命名空间映射，无法按 PSR-4 自动定位 - 一旦多个库同名文件（比如都叫
Config.php）混在同一个include_path目录下，加载顺序决定行为，极易冲突 - Composer 的
autoload机制已成事实标准，include_path更适合放本地工具类、全局函数集等非 Composer 化的脚本
如果你硬要让某个非 Composer 库被自动发现，建议只把它加进 include_path，然后用 require_once 'MyUtils.php'; 显式加载，而不是指望自动加载器。
CLI 和 Web 环境的 include_path 可能不同
这是最容易忽略的一点：phpEnv 管理的 CLI PHP 和 Apache/Nginx 调用的 PHP 很可能是两个不同 php.ini 文件，导致你在终端跑通了，浏览器却报 failed to open stream。
- CLI 下执行
php --ini查配置路径 - Web 下建一个
info.php输出phpinfo()，搜索 “Loaded Configuration File” - 两者路径不同，就得分别改 —— 不要假设改一个就全生效
尤其当你用 phpEnv + Valet / Laravel Homestead / Docker 时，Web 侧根本没走 phpEnv 的 PHP，而是容器或系统自带的，这时候改 phpEnv 的 php.ini 完全无效。
