原因

ctx.params 是由 koa-router注入的，但 koa-router是一个路由中间件，而 api-params-verify是全局中间件，在执行顺序上全局中间件早于路由中间件，所以获取不到 ctx.params

解决方案

将全局中间件改为改为路由中间件

取消全局中间件的加载

在具体需要进行校验的路由控制器绑定参数校验中间件(apiParamsVerify)

module.exports = (app, router) => {
  const { project: projectController } = app.controller;

  const apiParamsVerify = app.middlewares.apiParamsVerify;

  router.get("/api/project/list/:params_data/list", apiParamsVerify, projectController.getList.bind(projectController));
}

简单的发送请求验证结果

axios.request({
  method: 'get',
  url: '/api/project/list/2/list',
  params: {
    params_data_1: 1
  },
})

看到控制台可以分别拿到 path、query等参数的信息

缺点：每次想要进行参数校验的时候，在每个控制器路由请求都需要绑定中间件(太麻烦)，可以抽离之前的校验，分成 path参数校验和其他(header、query)参数校验，将 path参数校验逻辑抽离成一个新的中间件 apiPathVerify，在需要进行一些路径参数校验的控制器进行校验即可。

调整参数校验中间件执行顺序

问题的产生是因为 洋葱模型 中的加载，全局中间件会比路由中间件先加载，所以可以修改等路由加载完再来进行参数校验。

总结

1. 如果执行顺序不想改变的可以抽离单独的 path 校验中间件，在单独需要进行校验的 api 进行拦截
2. 如果不想改动太大代码的修改校验执行时机

相识

作为一名程序猿👨‍🦲，最熟悉的两个按键那就是 CV 了，这种 CV 不止是从网上或者找 AI 寻找答案后复制粘贴到我们的项目代码中，还有一层意思也是：在一个项目中重复的代码为了节省时间直接 复制粘贴 修改一些字段然后进行接口对接🙋‍♂️，然后就愉快😆的提交代码了。但这样确实一时爽，后面要改功能，增加新功能之类的都会让你如履薄冰🥶。

之后为了防止我的石山越长越高，就会将重复的功能抽离出来，在基本的功能之外就会对其想一想🤔还有没有可能拓展的功能？尽量就把他抽离出来，后续 leader 呼唤要修改功能的时候，就不用“到处跑”了。

上面提到的是作为在开发阶段，我对我自己的代码进行了一些 “抽离” 来使我后面的开发更简便，但还有一种 “魔法”，这个修改就不是在开发时的 “抽离” 了，转变而成的它 居然😲在编译的时候就进行一些的 “魔法攻击”，它有一个响亮的名字—— Loader。

相遇

本期的主人公—— Elpis-core。作为一名编译时的魔法攻击者，他会在应用启动之前，读取所有相关约定好的规则来进行自动加载组件和各种配置信息👍，除此之外还有其他优点，如：

1. 约定大于配置：通过固定文件目录结构和命名规范 -> 自动加载模块，从而减少手动的 import
2. 模块化管理：每个功能模块独立管理，诸如路由模块、中间件、服务层、控制器、配置文档等，便于功能维护与拓展
3. 灵活性：支持自定义扩展(功能、配置、模块等)

相知

看到这里，是不是也跟我一样（小白吃惊😮），居然还能这么搞 懒人工具。

"懒"是一些需求的根源

——爱偷懒的程序员

接下来，我准备与你来分享这个 魔法 背后的秘密（一点点吧，主要我也是刚开始学习🤣）

目录结构

整个项目的入口🚪就是根目录下的 index.js。

Loader

在 ElipisCore 中就是一个加载器系统(Loader)，主要作用就是在应用启动时自动加载和初始化各种配置信息。

在 Loader下的每个子模块都是在约定下去指定目录寻找指定文件进行加载

├── app/                    # 业务代码目录
│   ├── controller/        # 控制器层：处理请求响应
│   ├── service/          # 服务层：业务逻辑
│   ├── middleware/       # 中间件：请求处理管道
│   ├── router-schema/    # API 参数校验规则
│   └── extend/          # 功能扩展
└── elpis-core/           # 框架核心
    └── loader/          # 自动加载器

比如拿一个我们作为萌新😳最容易理解的 controller loader。

 /*
 * 例子:
 * app/controller
 *  |
 *  | -- custom-module
 *    | 
 *    | -- custom-controller.js
 * 
 *  => app.controller.customModule.customController
*/

至此，我们的装备🗡已经做好归类，想要什么类型就能快速定位，但面对强大的怪物，还得再做一套完整的计划。

app

从 Loader出来之后我们就已经是又有🛡又有🗡，但不会用呀💭

这时候就要介绍我们的好邻居们（中间件、路由、控制器、服务层等），他们每个家族的🏠住址就在 app中，而且他们每个家族里面也都有好多性（类）格（型）的兄弟姐妹，比如中间价家族就还有分异常处理部落、api校验部落和api签名认证部落等，为什么说他们是我的好邻居呢？因为在外头有人要挑事他们总会挡在我前面，其中就中间件家族最仗义了，总是冲在最前面。

相伴

由上面介绍应该可以知道我们面对不同等级的困难也有了一定的应对措施，但回到现实(🐂🐎)，这对开发又有什么好处呢？

问题又回到了一开始的我们的相遇，优点已经大概罗列的，但

规矩是死的，人是活的。

虽然有了良好的开发规范和约定，但还是得靠我们自己遵守，其次就是👆不要逼得太紧，🐕急了都会跳墙呢，更何况人呢？所以约定在紧急关头上🤔，我觉得还是不太管用的。

但至少我们知道能这样做！可以来提高我们的开发效率和降低维护成本，这已经就相当不错啦~

一、前言

在项目开发或者面试中经常出现下面这种判断：

console.log({} - {})
console.log([] - [])
console.log([] + [1, 2])
console.log([] == ![])
console.log({} == {})

结果分别是：NaN、0、1,2、true、false

二、包装类

包装类是我们理解隐式转化的基础工具,是理解隐式转化的根基。

js中包装类分为：Boolean()、Number()、String()。

Boolean()

Boolean()只有两种值：true和false

其中值为false的称为<font style="color:rgb(37, 41, 51);">falsey</font>或虚值，分别包括0、null、undefined、false、''，NaN；

而值为`true`的称为`truth`，除了`falsey`其他的返回都是`true`

Number()

Number()的处理就分为对 基础类型 的处理和 引用类型 的处理。

基础类型

console.log(Number(null)) // 0
console.log(Number(undefined)) // MaM
console.log(Number('1')) // 1
console.log(Number('')) // 0
console.log(Number(NaN)) // NaN
console.log(Number('1ab') // NaN
console.log(Number(false)) // 0
console.log(Number(true)) // 1

其中为NaN的数值分别有undefined、null、'1ab'

null表示"没有对象"，即该处不应该有值。 undefined表示"缺少值"，就是此处应该有一个值，但是还没有定义。

而'1ab'为NaN是因为字符串转换中出现了非数字的就会转换成NaN

引用类型

假如我们现在有下面这么一个对象：

  const obj = {
    toString() {
      return 2
    },
    valueOf() {
      return 1
    }
  }

如果用Number()去取值的时候就会调用到valueOf()方法，此时会返回 1 ，但如果改写 valueOf() { return {} }的话就会去调用 toString()， 此时返回 2

所以Number(引用类型)的逻辑过程就是：

String()

String()就是跟Number()相反，先调用toString()然后再看valueOf()

const obj = {
    toString() {
      return {}
    },
    valueOf() {
      return 1    
    }
}
console.log(String(obj)) // 1
console.log(String({})) // [object Object]

3 < 2 < 1 和 2 < 1 < 1

两个输出都是true，第一个符合数学公式，第二个就涉及到隐式转换了

1. 比较 2 < 1 结果为 fasle
2. 现在就是 false < 1 ，Number(false) 为0
3. 现在就是 0 < 1， 结果为 true

三、隐式转换规则

boolean 隐式转换触发

1. if
2. switch
3. while
4. for(;;)
5. &&
6. ||
7. !
8. !!
9. ? : 三元运算

number 隐式转换触发

用到数字运算符的地方都会进行转换：+ - * / == ~~ & | ~ ^ << <<<

string 隐式转换触发

+ 且两边大于等于1个string类型. 除了有 symbol类型之外

console.log(1 + '2' + '2') // '122'
console.log(1 + + '2' + '2') // '32'
console.log('A' - 'B' + '2') // 'NaN2'
console.log('A' - 'B' + 2) // NaN

1. 用 + 包裹，全部就转换为字符串后相加操作
2. +'2' 会先进行 number 转换，变成1 + 2 = 3，然后遇到 + 在进行string转换
3. 'A' - 'B' 会先进行 number 转换，变成 NaN，然后string转换
4. 同上

四、需要注意的点

console.log((123).toString()) // 123
console.log(undefined.toString()) // 报错
console.log(null.toString()) // 报错

undefined和null并没有包装类,它们是基础类型,所以没有toString()方法

五、面试题

console.log([] == ![]) // true

1. 一看到 == 就会想到两边会进行 Number转换
2. Number([]) 会调用到 Array.prototype.toSting()，得到的是一个空字符串 '' ，用Number转换后就会变成0
3. 右边 ![]会先进行 Boolean 转换，[] 不是 falsey，所以Boolean([])为 true
4. !true 再进行Numebr 转换就会变成 0
5. 所以最终就是0 == 0，结果为true

六、奇奇怪怪的题目

66.toString() // 报错: Invalid or unexpected token
66..toString() // '66'
66.6.toString() // '66.6'
66...toString() // 报错: Unexpected token '.'