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

最后

针对最近很多人都在面试，我这边也整理了相当多的面试专题资料，也有其他大厂的面经。希望可以帮助到大家。

最新整理面试题

上述的面试题答案都整理成文档笔记。也还整理了一些面试资料&最新2021收集的一些大厂的面试真题

最新整理电子书

最新整理大厂面试文档

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持。

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取

▐  寻找"金额"

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

一方面，这是因为 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: 直接赋默认值

根据上面的 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解构语法赋默认值

经过对上一个 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: "||"运算符赋默认值

经过上面的两个例子说明，想必 "||"运算符赋默认值 的检测已经不在话下。不过这里需要特别注意一点：在实际的代码中，= 右侧的赋值表达式可能并不像例子中给的 “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 做代码扫描的基本原理，最后再以实际仓库的扫描结果验证检测效果。目前来看，针对一些通用型的问题，通过代码扫描确实能够发现一些藏在代码中的潜在资损/舆情风险。但是对于一些和业务逻辑强相关的资损风险目前仍不容易检测，这还需从其他角度点进行突破。

✿  拓展阅读

**作者|**菉竹

**编辑|**橙子君
**出品|**阿里巴巴新零售淘系技术

总结

互联网大厂比较喜欢的人才特点：对技术有热情，强硬的技术基础实力；主动，善于团队协作，善于总结思考。无论是哪家公司，都很重视高并发高可用技术，重视基础，所以千万别小看任何知识。面试是一个双向选择的过程，不要抱着畏惧的心态去面试，不利于自己的发挥。同时看中的应该不止薪资，还要看你是不是真的喜欢这家公司，是不是能真的得到锻炼。其实我写了这么多，只是我自己的总结，并不一定适用于所有人，相信经过一些面试，大家都会有这些感触。

**另外本人还整理收藏了2021年多家公司面试知识点以及各种技术点整理 **

下面有部分截图希望能对大家有所帮助。

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取

一个双向选择的过程，不要抱着畏惧的心态去面试，不利于自己的发挥。同时看中的应该不止薪资，还要看你是不是真的喜欢这家公司，是不是能真的得到锻炼。其实我写了这么多，只是我自己的总结，并不一定适用于所有人，相信经过一些面试，大家都会有这些感触。

**另外本人还整理收藏了2021年多家公司面试知识点以及各种技术点整理 **

下面有部分截图希望能对大家有所帮助。

[外链图片转存中…(img-frRITBDs-1715812229449)]

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取