webman默认不自动加载config/子目录,需在config/下创建extra.php文件显式返回子目录配置数组;子目录配置须以return []形式定义,调用时用config('子目录名.键'),修改后需restart生效。

Webman 的 config/ 目录不自动加载子目录?必须手动注册 extra 配置
Webman 默认只加载 config/ 根目录下的 PHP 文件(如 app.php、database.php),不会递归扫描子目录。你把配置放到 config/extra/wechat.php 或 config/api/v1.php,Webman 完全无视——不是读取失败,是压根不找。
解决办法是显式声明一个入口文件(惯例叫 extra.php)来桥接子目录内容:
-
config/extra.php必须存在,且必须return一个数组,键为配置名(如wechat),值为对应子配置数组 - 不能用
include或require后不return,否则config('wechat')拿到的是null - 子目录路径建议用
config_path('extra')获取,避免硬编码;scandir()前要加is_dir()判断,防止目录不存在时警告 - 每个子配置文件(如
config/extra/wechat.php)也必须以return [ ... ];结尾,不能只写$config = [ ... ];
示例 config/extra.php:
<?php $path = config_path('extra');
if (!is_dir($path)) {
return [];
}
$res = [];
foreach (scandir($path) as $item) {
if (pathinfo($item, PATHINFO_EXTENSION) !== 'php') continue;
$file = $path . '/' . $item;
$name = pathinfo($item, PATHINFO_FILENAME);
$res[$name] = include $file;
}
return $res;调用自定义配置时 config() 返回 null?检查 key 名是否匹配、是否已加载
config('wechat.app_id') 返回 null,常见原因不是语法错,而是 key 路径和实际结构对不上。Webman 的 config() 是点号分隔的“扁平化”访问,但前提是配置数据本身是多维数组,且已被正确合并进全局配置池。
- 确保
config/extra.php已被 Webman 加载:它必须在config/根目录下,且文件名就是extra.php(不能叫extra_config.php) -
config('wechat')对应的是config/extra/wechat.php中return的整个数组;如果想读wechat.php里的['app']['id'],得写config('wechat.app.id'),不是config('wechat.app_id') - 开发时改了
extra/下的文件,需重启 Webman worker(php webman restart),因为配置在启动时一次性加载并缓存,不支持热重载 - 若用
var_dump(config())看不到你的配置项,说明extra.php执行出错或返回空数组——加error_log(print_r($res, true), 3, '/tmp/webman-config.log')快速定位
parse_ini_file 读 INI 配置?Webman 不原生支持,得自己封装
Webman 的配置系统只认 PHP 数组格式(即 return [...]),不支持直接用 parse_ini_file() 或 json_decode() 加载 .ini / .json 文件。你放个 config/database.ini,即使内容合法,Webman 也会跳过它。
- 如确需用 INI 格式,只能在
config/database.php里手动调用:return parse_ini_file(__DIR__ . '/database.ini', true, INI_SCANNER_RAW); - 必须加
file_exists()和错误判断,parse_ini_file()在文件不存在或语法错误时静默返回false,不抛异常 - INI 中的
on/off、yes/no默认转布尔,易引发误判;务必传INI_SCANNER_RAW保持字符串原样,后续再用filter_var($val, FILTER_VALIDATE_BOOLEAN)显式转换 - JSON/YAML 更不推荐:需额外扩展(如
ext-yaml),且 Webman 启动阶段无容错机制,解析失败会导致整个服务无法启动
生产环境配置敏感信息?别塞进 config/,用环境变量注入
把数据库密码、API 密钥写死在 config/ 下任何 PHP 文件里,等于把密钥明文提交进 Git——这是 Webman 项目上线前最常被安全审计打回的问题。
- Webman 支持
$_ENV和getenv(),应在config/database.php等文件中用$_ENV['DB_PASSWORD'] ?? 'default'替代硬编码 - 环境变量应在 Webman 启动前注入:Docker 用
environment:,Supervisor 用environment=,PHP-FPM 用env[DB_PASSWORD]=xxx - 不要在
config/extra.php或子配置里调用getenv()动态拼接路径——环境变量加载时机早于配置加载,但部分部署方式(如某些容器初始化顺序)会导致未就绪,应统一在顶层配置文件中完成注入 - 本地开发可用
.env文件,但 Webman 不自带 Dotenv 加载器,需自行用vlucas/phpdotenv在start/bootstrap.php开头加载
最易被忽略的一点:Webman 的配置合并是浅拷贝,config/extra.php 返回的数组如果含引用或闭包,运行时可能引发不可预期行为;所有配置值必须是纯数据结构。
php免费学习视频:立即使用
踏上前端学习之旅,开启通往精通之路!从前端基础到项目实战,循序渐进,一步一个脚印,迈向巅峰!











