Config 配置

    配置的管理有多种方案，以下列一些常见的方案

    1. 使用平台管理配置，应用构建时将当前环境的配置放入包内，启动时指定该配置。但应用就无法一次构建多次部署，而且本地开发环境想使用配置会变的很麻烦。
    2. 使用平台管理配置，在启动时将当前环境的配置通过环境变量传入，这是比较优雅的方式，但框架对运维的要求会比较高，需要部署平台支持，同时开发环境也有相同痛点。
    3. 使用代码管理配置，在代码中添加多个环境的配置，在启动时传入当前环境的参数即可。但无法全局配置，必须修改代码。

    我们选择了最后一种配置方案，配置即代码，配置的变更也应该经过 review 后才能发布。应用包本身是可以部署在多个环境的，只需要指定运行环境即可。

    框架支持根据环境来加载配置，定义多个环境的配置文件，具体环境请查看运行环境配置

    config.default.js 为默认的配置文件，所有环境都会加载这个配置文件，一般也会作为开发环境的默认配置文件。

    当指定 env 时会同时加载对应的配置文件，并覆盖默认配置文件的同名配置。如 prod 环境会加载 config.prod.js 和 config.default.js 文件，config.prod.js 会覆盖 config.default.js 的同名配置。

    1. // 配置 logger 文件的目录，logger 默认配置由框架提供
    2. module.exports = {
    3.   logger: {
    4.   },
    5. };

    配置文件也可以简化的写成 exports.key = value 形式

    配置文件也可以返回一个 function，可以接受 appInfo 参数

    2. const path = require('path');
    3. module.exports = appInfo => {
    4.   return {
    5.     logger: {
    6.       dir: path.join(appInfo.baseDir, 'logs'),
    7.     },
    8.   };
    9. };

    内置的 appInfo 有

    appInfo.root 是一个优雅的适配，比如在服务器环境我们会使用 /home/admin/logs 作为日志目录，而本地开发时又不想污染用户目录，这样的适配就很好解决这个问题。

    请根据具体场合选择合适的写法，但请确保没有写出以下代码：

    比如在 prod 环境加载一个配置的加载顺序如下，后加载的会覆盖前面的同名配置。

    1. -> 框架 config.default.js
    2. -> 应用 config.default.js
    4. -> 框架 config.prod.js
    5. -> 应用 config.prod.js

    注意：插件之间也会有加载顺序，但大致顺序类似，具体逻辑可。

    配置的合并使用 extend2 模块进行深度拷贝， fork 自 extend，处理数组时会存在差异。

    根据上面的例子，框架直接覆盖数组而不是进行合并。

    框架在启动时会把合并后的最终配置 dump 到 run/application_config.json（worker 进程）和 run/agent_config.json（agent 进程）中，可以用来分析问题。

    • 如密码、密钥等安全字段，这里可以通过 config.dump.ignore 配置，必须是 类型，查看默认配置。
    • 如函数、Buffer 等类型，JSON.stringify 后的内容特别大

    还会生成 run/application_config_meta.json（worker 进程）和 run/agent_config_meta.json（agent 进程）文件，用来排查属性的来源，如

    1. {
    2.   "logger": {
    3.     "dir": "/path/to/config/config.default.js"
    4.   }