AST 代码扫描实战：如何保障代码质量

2020 年 618 大促已经过去，作为淘系每年重要的大促活动，淘系前端在其中扮演着什么样的角色，如何保证大促的平稳进行？又在其中应用了哪些新技术？淘系前端团队特此推出「618 系列|淘系前端技术分享」，为大家介绍 618 中的前端身影。

本篇来自于频道与D2C智能团队的菉竹，为大家介绍本次 618 大促中是如何用代码扫描做资损防控的。

前言

现如今，日常业务的资损防控工作在安全生产环节中已经变得越来越重要。尤其是每逢大促活动（譬如本次 618 大促），一旦出现资损故障更容易引发重大损失。就目前来说，有效的防控手段一般有：

项目上线前 code review ，通过预演提前发现问题
线上实时监控对账，出现问题时执行预案，及时止血

由上可以看出，及时止血只能减小资损规模，要想避免资损还得靠人工 code review 在项目上线之前发现问题。

然而，一方面 code review 需要额外的人工介入，且其质量参差不齐，无法得到保障；另一方面，高质量的 code review 也会花费较多时间，成本较高。

那么有没有一种两全其美的方法：以一种低成本的方式，自动发现代码中存在的资损风险，从而保障代码质量？答案是：代码扫描！

我们希望每次代码提交时都能自动检测出代码中的资损风险并给出告警，从而在研发阶段就能提前发现问题并及时修复。接下来，本文就将介绍本次 618 资损防控中我们是 如何用 AST 来做静态代码扫描的 。

什么是AST

在上文中，我们提到可以利用 AST 来做静态代码扫描，检测代码中是否存在某些可能造成资损或者舆情的场景。那么问题来了，AST 是什么呢？

在计算机科学中，抽象语法树（Abstract Syntax Tree，AST）或简称语法树（Syntax tree），是源代码语法结构的一种抽象表示。它以树状的形式表现编程语言的语法结构，树上的每个节点都表示源代码中的一种结构。

这是一段引自百科上的解释，什么意思呢？让我们一起来看下面这个例子：

UfqEruF.png!web

可以看到，非常简单的一句初始化赋值代码 var str = "hello world" 被拆解成了多个部分，并用一棵树的形式表示了出来。（如果想查看更多源代码对应的 AST，可以使用神器 astexplorer 在线尝试）

其实，我们每天日常工作都在使用的 js 代码编译工具 — Babel，它也离不开 AST。为了将 ES6 甚至更高版本的 js 语法转换成浏览器兼容性更好的 ES5 代码，Babel 每次都需要先将源代码解析成 AST，然后修改 AST 使其符合 ES5 语法，最后再重新生成代码。总结一下就是3个阶段：parse -> transform -> generate。

到这儿，也许你的心中会冒起一个想法："咦？前文就在说可以用 AST 做代码扫描，而 Babel 又恰好已经做了解析 AST 的工作，难道..." 没错，当你带着这个疑惑打开 Babel官网时，你会发现：真香~~~

Babel 不但完成了 AST 的解析工作，而且由于其编译 js 代码的使命，它还提供了一套完善的 visitor 插件机制用于扩展，而种种的这些都为我们的代码扫描工作创造了完美的条件。

const parser = require('@babel/parser');
const traverse = require('@babel/traverse').default;
// 编写自定义规则插件
const visitor = {};
// 源代码
const code = `var str = "hello world";`;
// code -> ast
const ast = parser.parse(code);
// 用自定义规则遍历ast(即代码扫描)
traverse(ast, visitor);

如上所示，利用 Babel 提供的能力来做代码扫描就是如此简单，唯一要做的就是结合我们自定义的资损/舆情规则来编写 Babel 开放的 visitor 插件。（有关"如何自定义 Babel 插件"可以查看这份 Babel插件手册，该文档介绍了如何编写一个 Babel 自定义插件，也是后文的基础）

解决问题

在简单介绍完 AST 后，让我们回归到本文的核心问题：面对以下这些可能发生资损故障的场景，什么"千奇百怪"的代码都可能出现，我们该如何做检测呢？

前端金额赋默认值
前端金额计算错误
前端写死固定金额/积分
...

▐ 寻找"金额"

根据上文的描述，我们知道 "金额" 在前端就是一个高危分子，有关它的操作都容易造成资损。

一方面，这是因为 js 的数字"精度"问题（老生常谈的 "0.1 + 0.2 = 0.300000004" 问题）；另一方面，金额计算本就应该放在服务端更安全。

因此，为了避免潜在的风险，所有的金额计算操作都应该由服务端计算后下发给前端，而前端只做展示作用。这也正是代码扫描的关键一步，我们需要检测代码中是否含有金额的计算操作。

为了找出代码中的金额计算，首先要做的就是识别代码中的 "金额变量"。对于这个问题，我们可以使用简单粗暴却又行之有效的方法：正则匹配。由于大家的金额变量名取得都比较有规律（就比如 xxxPrice，PS：可继续扩展），我们可以用一个简单的正则进行匹配：

const WHITE_LIST = ['price']; // TODO: 可扩展

const PRICE_REG = new RegExp(WHITE_LIST.map(s => s + '$').join('|'), 'i');

根据 Babel 解析得到的 AST，由于变量名均是 Identifier 类型的节点，所以我们可以用一个简单的规则来匹配所有的金额变量：

const isPrice = str => PRICE_REG.test(str);
const visitor = {
  Identifier(path) {
    const {id} = path.node;
    if(isPrice(id.name)) {
      // 金额变量 匹配成功！
    }
  }
};

▐ 小试牛刀

解决金额变量的定位问题后，我们再来看看 "金额赋默认值" 的检测问题。

// case 1: 直接赋默认值
const price = 10;
// case 2: ES6解构语法赋默认值
const {price = 10} = data;
// case 3: "||"运算符赋默认值
const price = data.price || 10;
// ...

如上所示，虽然金额赋默认值有多种写法，但是当它们被解析成 AST 后，我们却可以将其逐一击破。说到这，就不得不再次祭出 astexplorer 神器将上述代码分析一波。

case 1: 直接赋默认值

eeUj2mi.png!web

根据上面的 code vs AST 关系图可以看到，我们只要找到 VariableDeclarator 节点，且同时满足 id 是金额变量，init 是大于 0 的数值节点这两个条件即可。代码如下：

const t = require('@babel/types');
const visitor = {
  VariableDeclarator(path) {
    const {id, init} = path.node;
    if(
      t.isIdentifer(id) &&
      isPrice(id.name) &&
      t.isNumericLiteral(init) &&
      init.value > 0
    ) {
      // 直接赋默认值 匹配成功！
    }
  }
};

case 2: ES6解构语法赋默认值

QjQv63B.png!web

经过对上一个 case 的解析，我们其实已经初步掌握了如何用 AST 做代码扫描的要领，再来看 ES6解构语法赋默认值的检测。观察上面的关系图，我们可以得出结论：找到 AssignmentPattern 节点，且同时满足 left 是金额变量，right 是大于 0 的数值节点这两个条件。代码如下：

const t = require('@babel/types');
const visitor = {
  AssignmentPattern(path) {
    const {left, right} = path.node;
    if (
      t.isIdentifer(left) &&
      isPrice(left.name) &&
      t.isNumericLiteral(right)
      && right.value > 0
    ) {
      // ES6解构语法赋默认值 匹配成功！
    }
  }
};

case 3: "||"运算符赋默认值

ZzQr22r.png!web

经过上面的两个例子说明，想必 "||"运算符赋默认值的检测已经不在话下。不过这里需要特别注意一点：在实际的代码中，= 右侧的赋值表达式可能并不像例子中给的 "data.price || 10" 这般简单，而是可能夹杂着一定的逻辑运算。对于这类情况，我们需要改变策略：遍历右侧的赋值表达式中是否包含 "|| 正数" 的模式。

const t = require('@babel/types');
const visitor = {
  VariableDeclarator(path) {
    const {id, init} = path.node;
    if(t.isIdentifer(id) && isPrice(id.name)) {
      path.traverse({
        LogicalExpression(subPath) {
          const {operator, right} = subPath.node;
          if(
            operator === '||' &&
            t.isNumericLiteral(right) &&
            right.value > 0
          ) {
            // "||"运算符赋默认值 匹配成功！
          }
        }
      });
    }
  }
};

▐ 变量追踪

根据上文的介绍，其实一些基础规则的代码扫描已经可以实现，然而现实中提交的代码往往会比上面给出的例子复杂得多。就拿金额计算来说，我们可以用下面的 visitor 来匹配任何有关金额的四则运算：

const t = require('@babel/types');
const Helper = {
  isPriceCalc(priceNode, numNode, operator) {
    return (
      t.isisIdentifier(priceNode) &&
      isPrice(priceNode.name) &&
      (t.isNumericLiteral(numNode) || t.isIdentifier(numNode)) &&
      ['+', '-', '*', '/'].indexOf(operator) > -1
    );
  }
};
const checkPriceCalcVisitor = {
  BinaryExpression(path) {
    const {left, right, operator} = path.node;
    if(
      Helper.isPriceCalc(left, right, operator) ||
      Helper.isPriceCalc(right, left, operator)
    ) {
      // 金额计算 匹配成功！
    }
  }
}

然而，上面的规则却只能检测对金额变量的直接运算，一旦碰上函数调用就无效了。比如以下代码：

const fen2yuan = (num) => {
  return num / 100;
};
const ret = fen2yuan(data.price);

这是一个再简单不过的分转元金额单位换算函数，由于形参不具备金额变量名的特征，先前的规则将无法成功检测。为了解决 "变量追踪" 这个问题，我们还需引入 Babel 中的 Scope 能力。根据官方文档介绍，一个 scope 可以被表示成：

// 一个scope
{
  path: path,
  block: path.node,
  parentBlock: path.parent,
  parent: parentScope,
  bindings: [...]
}
// 其中的一个binding
{
  identifier: node,
  scope: scope,
  path: path,
  kind: 'var',
  referenced: true,
  references: 3,
  referencePaths: [path, path, path],
  constant: false,
  constantViolations: [path]
}

有了上面这些信息，我们就可以查找任何一个变量的声明以及任何一个绑定的所有引用。什么意思呢？

前文提到的变量追踪问题在于：原本是金额变量名的实参在函数调用时，形参可能变成了和金额无关的变量名。但是现在，我们可以借助 scope 顺藤摸瓜，先找到该函数的声明，然后根据参数的位置信息重新建立实参和形参之间的关系，最后再用 binding 检测函数体内是否含有对形参的四则运算。

const t = require('@babel/types');
const Helper = {
  // ...
  findScope(path, matchFunc) {
    let scope = path.scope;
    while(scope && !matchFunc(scope)) {
      scope = scope.parent;
    }
    return scope;
  }
};
const checkPriceCalcVisitor = {
  // ...
  CallExpression(path) {
    const {arguments, callee: {name}} = path.node;
    // 匹配金额变量作为实参的函数调用
    const priceIdx = arguments.findIndex(arg => isPrice(arg));
    if(priceIdx === -1) return;
    
    // 寻找该函数的声明节点
    const foundFunc = Helper.findScope(path, scope => {
      const binding = scope.bindings[name];
      return binding && t.isFunctionDeclaration(binding.path.node);
    });
    if(!foundFunc) return;
    
    // 匹配实参和形参之间的位置关系
    const funcPath = foundFunc.bindings[name].path;
    const {params} = funcPath.node;
    const param = params[priceIdx];
    if(!t.isIdentifier(param)) return;
    
    // 检测函数内是否有对形参的引用
    const renamedParam = param.name;
    const {referencePaths: refPaths = []} = funcPath.scope.bindings[renamedParam] || {};
    if(refPaths.length === 0) return;
    
    // 检测形参的引用部分是否涉及金额计算
    for(const refPath of refPaths) {
      // TODO: checkPriceCalcVisitor支持指定变量名的检测
      refPath.getStatementParent().traverse(checkPriceCalcVisitor);
    }
  }
}

如上所示，借助 scope 和 binding 的能力，我们就基本解决了 "变量追踪" 问题。

检测效果

经过前文对基本原理介绍后，我们再来看下实际的检测效果。从代码扫描上线之后到本次 618 活动目前为止，我们对一批前端代码仓库进行了扫描，共有 1/7 的仓库都命中了规则。下面挑了几个例子来感受下藏在代码中的"毒药"~

Bad code 1:

let {
  // ...
  rPrice = 1
} = res.data || {};

如上所示，当服务端返回的数据异常时，一旦 res.data 为空，那么 rPrice 就会获得默认值 1。经过代码分析后发现 rPrice 代表的就是红包面额，因此理论上就可能会造成资损。

Bad code 2:

class CardItem extends Component {
  static defaultProps = {
    itemPrice: '99',
    itemName: '...',
    itemPic: '...',
    // ...
  }
    // ...
}

如上所示，该代码应该是在开发初期 mock 了展示所需的数据，但是在后续迭代时又没有删除 mock 数据。一旦服务端下发的数据缺少 itemPrice 字段，所有的价格都将显示 99，这也是颗危险的定时炸弹。

Bad code 3:

const [price, setPrice] = useState(50);

如上所示，这个 hooks 的使用例子默认就会给 price 赋值 50，如果这是一个红包或券的面额，意味着用户可能就领到了这 50 元，从而也就造成了资损。

Bad code 4:

// price1为活动价，price2为原始价

let discount = Math.ceil(100 * (price1 / 1) / (price2 / 1)) / 10;

如上所示，这是一个前端计算折扣的代码案例。按照前文提到的约定，凡是涉及到金额计算的逻辑都应该放在服务端，前端只做展示逻辑。因此，如果能检测出这类代码，还是可以从源头上避免不必要的风险。

Bad code 5:

Toast.show('恭喜您获得双11红包');

如上所示，这是一段字符串常量中包含大促关键字（双11）的代码。由于目前是 618 大促，如果用户看到这个 toast 提示就不合适了，虽然不会造成资损，但可能会引发舆情。因此，原则上来说，前端使用的兜底文案就应该是通用型文案，凡是此类带"时效性"的文案要么走配置下发，要么服务端下发。

总结与展望

本文先对 AST 做了简单介绍，接着围绕资损防控问题介绍了如何用 AST 做代码扫描的基本原理，最后再以实际仓库的扫描结果验证检测效果。目前来看，针对一些通用型的问题，通过代码扫描确实能够发现一些藏在代码中的潜在资损/舆情风险。但是对于一些和业务逻辑强相关的资损风险目前仍不容易检测，这还需从其他角度点进行突破。

✿ 拓展阅读

eaYnmeu.png!web