后端Web框架【免费下载链接】egg Born to build better enterprise frameworks and apps with Node.js Koa项目地址https://gitcode.com/gh_mirrors/egg11/egg点击查看免费下载本指南以 Egg 框架当前仓库 egg 为主线系统讲解其配置即代码的设计理念、多环境配置文件组织方式、appInfo动态配置、应用/框架/插件三级配置合并顺序与数组覆盖规则以及插件开关与引入方法。读完本文你将掌握从编写config/*.js到通过app.config消费合并结果、借助run/*_config.json排查配置问题的完整实战链路。一、配置管理策略与配置即代码理念框架提供了强大且可扩展的配置功能可以自动合并应用、插件、框架的配置按顺序覆盖且可以根据环境维护不同的配置。合并后的配置可直接从app.config获取。在生产实践中团队通常会面对三种常见的配置管理方案官方文档列举平台管理构建期注入应用构建时将当前环境的配置放入包内启动时指定该配置。缺点应用无法一次构建多次部署无法做到一次构建、处处运行而且本地开发环境想使用配置会变得很麻烦。平台管理环境变量注入在启动时将当前环境的配置通过环境变量传入。这是比较优雅的方式但对运维的要求较高需要部署平台支持同时开发环境也有相同的痛点。代码管理在代码中添加多个环境的配置在启动时传入当前环境的参数即可。缺点是无法全局配置修改配置必须改动代码。Egg 选择了最后一种方案即配置即代码Config as Code。其核心理念是配置的变更应当像代码一样经过 review 后才能发布应用包本身可以部署在多个环境只需要在启动时指定运行环境即可。这意味着配置随应用一起版本化、可审计、可回滚。二、多环境配置文件组织框架支持根据运行环境加载不同的配置文件各环境配置文件统一放在应用根目录的config/目录下。官方文档给出的标准目录结构如下config |- config.default.js |- config.test.js |- config.prod.js |- config.unittest.js - config.local.jsconfig.default.js为默认配置文件所有环境都会加载这个文件一般也作为开发环境的默认配置文件。当指定env时会同时加载对应的环境配置文件并覆盖默认配置文件中的同名配置。例如prod环境会同时加载config.prod.js和config.default.js且config.prod.js会覆盖config.default.js中的同名配置项。运行环境的具体判定逻辑local/test/prod/unittest等参见 运行环境配置 一文。本仓库自身的真实配置即遵循该规范config/config.default.js —— 框架默认配置函数形式接收appInfoconfig/config.local.js —— 本地开发环境覆盖配置config/config.unittest.js —— 单元测试环境覆盖配置。测试夹具也展示了各环境文件的用法例如 context-config-app 的 config 目录 同时包含config.js会被当作config.default.js处理与config.local.js用于验证不同环境下的配置差异。三、配置的三种写法3.1 导出对象覆盖框架配置配置文件返回的是一个 object 对象可以覆盖框架的一些配置应用也可以将自己的业务配置放到这里统一管理。例如覆盖 logger 文件目录logger 的默认配置由框架提供// config/config.default.js module.exports { logger: { dir: /home/admin/logs/demoapp, }, };3.2 简写形式exports.key value配置文件也可以简写成exports.key value的形式适合只覆盖少量配置项的场景exports.keys my-cookie-secret-key; exports.logger { level: DEBUG, };本仓库的测试夹具大量使用这种写法例如 demo 应用的 config.default.jsexports.keys foo; exports.proxy true; exports.buffer Buffer.from(test);3.3 导出函数接收 appInfo配置文件还可以返回一个 function该函数接收一个名为appInfo的参数从而在配置中动态引用应用自身的路径等信息。例如将 logger 目录放到代码目录下// config/config.default.js const path require(path); module.exports appInfo { return { logger: { dir: path.join(appInfo.baseDir, logs), }, }; };框架内置的appInfo字段如下appInfo说明pkgpackage.json内容name应用名同pkg.namebaseDir应用代码的目录HOME用户目录如 admin 账户为/home/adminroot应用根目录仅在local和unittest环境下为baseDir其他环境为HOMEappInfo.root是一个非常优雅的环境适配在服务器环境我们会使用/home/admin/logs作为日志目录而本地开发时又不想污染用户目录这样的适配可以很好地解决这个问题。框架默认 logger 配置正是这样实现的见 config/config.default.jsconfig.logger { dir: path.join(appInfo.root, logs, appInfo.name), // ... };也就是说生产环境下日志会写到$HOME/logs/应用名/而本地开发local环境则直接落在项目目录下无需任何额外判断。四、配置加载顺序应用 框架 插件应用、插件、框架都可以定义上述配置且目录结构完全一致但存在明确的优先级应用 框架 插件同时运行环境配置的优先级更高环境特定文件会覆盖 default 文件。以prod环境为例一个配置项的加载顺序如下后加载的会覆盖前面加载的同名配置- 插件 config.default.js - 框架 config.default.js - 应用 config.default.js - 插件 config.prod.js - 框架 config.prod.js - 应用 config.prod.js由此可以总结出两条实用规律在同一环境层级内应用配置永远压过框架与插件配置因此业务方无需修改框架源码即可定制任何行为环境文件永远覆盖默认文件因此基础配置写 default、环境差异写环境文件是最推荐的组织方式。注意插件之间也存在加载顺序受插件依赖关系影响但整体次序大致如上。具体逻辑可参考 加载器loader 文档本仓库的加载器实现位于 lib/loader/app_worker_loader.js、agent_worker_loader.js、index.js其中loadConfig()由应用启动时调用见 lib/egg.js 的this.loader.loadConfig()。五、合并规则深度拷贝数组直接覆盖配置的合并使用 extend2 模块进行深度拷贝。extend2 fork 自 extend在处理数组时存在差异const a { arr: [ 1, 2 ], }; const b { arr: [ 3 ], }; extend(true, a, b); // { arr: [ 3 ] }根据上面的例子框架直接覆盖数组而不是进行合并。这一点在写配置时需要特别注意如果你希望业务配置中的数组在合并后保留多个来源的元素需要自行处理框架层面不会做数组拼接。extend2同样是配置 dump 环节的核心工具在 lib/egg.js 的dumpConfigToObject()中合并后的最终配置会先通过extend(true, {}, { config: this.config, plugins: this.plugins })做一次深拷贝快照再写入磁盘保证 dump 出的文件是独立的、可安全序列化的副本。六、插件配置开关与引入在应用中可以通过config/plugin.js来控制插件的选项。6.1 开启 / 关闭内置插件框架内置了一些企业级应用常用的插件完整清单见 config/plugin.js包含onerror、session、i18n、watcher、multipart、security、development、logrotator、schedule、static、jsonp、view等。通过配置可以开启或关闭插件插件关闭后插件内的所有文件都不会被加载。// config/plugin.js —— 关闭内置的 i18n 插件 module.exports { i18n: { enable: false, }, };也可以简单地配置一个布尔值效果等价module.exports { i18n: false, };6.2 引入 npm 插件package 方式应用开发者可以根据业务需求引入其他插件只需要指定package配置// config/plugin.js —— 使用 mysql 插件 module.exports { mysql: { enable: true, package: egg-mysql, }, };package为一个 npm 模块名必须同时添加到package.json的dependencies中。框架会在node_modules目录中查找这个模块并以其作为插件入口{ dependencies: { egg-mysql: ^1.0.0 } }重要注意配置的插件即使只在开发期使用也必须是dependencies而不是devDependencies否则执行npm i --production安装生产依赖后框架将找不到该插件。6.3 引入本地插件path 方式也可以指定path来替代package引入应用自研的本地插件// config/plugin.js const path require(path); module.exports { mysql: { enable: true, path: path.join(__dirname, ../app/plugin/egg-mysql), }, };path必须是一个绝对路径这样应用可以把自己开发的插件直接放到应用目录中例如app/plugin目录。本仓库的插件加载测试夹具loader-plugin见 test/fixtures/apps/loader-plugin/config/plugin.js及loader-plugin-dep、loader-plugin-dep-recursive等应用分别验证了插件加载顺序、依赖关系与缺失依赖报错等行为可在 test/lib/core/loader/load_plugin.test.js 中查看对应测试用例。七、配置结果启动时自动 dump 与排查框架在启动时会把合并后的最终配置dump 到磁盘用于问题分析与排障run/application_config.json—— worker 进程的最终配置run/agent_config.json—— agent 进程的最终配置。run目录即config.rundir默认值为path.join(appInfo.baseDir, run)见 config/config.default.js。dump 文件中会隐藏两类字段安全相关字段如密码、密钥等。可通过config.dump.ignore配置忽略项该配置必须是Set类型。框架默认忽略列表见 config/config.default.jsdump: { ignore: new Set([ pass, pwd, passd, passwd, password, keys, masterKey, accessKey, // 忽略任何包含 secret 关键字的键 /secret/i, ]), },可以看到默认规则既包含精确的键名如password、keys也支持正则/secret/i匹配所有包含secret的键。测试夹具 demo 应用 中刻意配置了pass、pwd、password、mysql.passd、mysql.consumerSecret等字段正是用于验证 dump 时的脱敏逻辑。序列化后体积巨大的字段如Function、Buffer等类型JSON.stringify后的内容会特别大也会被隐藏。此外框架还会生成run/application_config_meta.jsonworker 进程和run/agent_config_meta.jsonagent 进程文件用来排查每个配置项来自哪个文件{ logger: { dir: /path/to/config/config.default.js } }这样在遇到配置被覆盖了但不知道为什么的问题时直接查看 meta 文件就能定位配置项的最终来源文件。从源码层面看dump 的实现位于 lib/egg.js 中应用 ready 后通过ready()回调触发dumpConfig()见 lib/egg.js该方法读取config.rundir、调用dumpConfigToObject()生成{ config, meta }快照再分别写入${type}_config.json与${type}_config_meta.json见 lib/egg.js。由于 dump 发生在 ready 之后启动期间对配置的所有修改都会被如实记录便于完整还原运行时真实状态。八、快速自查清单配置写在config/目录下环境差异用config.env.js表达公共配置放config.default.js需要引用应用路径时配置导出函数并使用appInfobaseDir、root、HOME、name、pkg记住合并顺序应用 框架 插件环境文件 默认文件且数组是覆盖而非合并插件开关写config/plugin.jsnpm 插件用package且必须进dependencies本地插件用绝对path排查配置问题时查看run/application_config.json最终值与run/application_config_meta.json来源文件密码等敏感字段会按config.dump.ignore自动脱敏业务新增敏感键时记得补充 ignore 规则。相关文档与源码索引官方文档Configuration 配置英文 | Config 配置中文环境判定运行环境配置 env加载器原理Loader 加载器框架默认配置config/config.default.js框架内置插件清单config/plugin.js配置 dump 实现lib/egg.js配置相关测试test/lib/core/config/config.test.js、test/lib/core/loader/load_plugin.test.js赞分享后端Web框架【免费下载链接】egg Born to build better enterprise frameworks and apps with Node.js Koa项目地址https://gitcode.com/gh_mirrors/egg11/egg点击查看免费下载相关推荐Egg 配置管理实战多环境配置、加载顺序与合并规则全解析Egg 配置管理实战多环境配置、加载顺序与合并规则全解析 导读 本文基于 Egg 官方文档《Config 配置》并结合仓库源码系统讲解 Egg 框架配置即后端Web框架Egg 框架配置机制全解析多环境加载、合并顺序与 dump 调试实战Egg 框架配置机制全解析多环境加载、合并顺序与 dump 调试实战 本文围绕 Egg本仓库即 Egg 框架与 Koa 的现代化 TypeScript 实现后端Web框架Kedro 配置基础使用 OmegaConfigLoader 管理项目配置、环境与合并规则Kedro 配置基础使用 OmegaConfigLoader 管理项目配置、环境与合并规则 导读 Kedro 项目中的所有可配置内容—— 参数与凭据 http数据工程工作流自动化创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考