▐  小试牛刀

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

// 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;

小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Java工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频

如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Java）

最后

针对以上面试题，小编已经把面试题+答案整理好了

面试专题

除了以上面试题+答案，小编同时还整理了微服务相关的实战文档也可以分享给大家学习

iuV0xPQq-1711382217917)]

[外链图片转存中…(img-BOntw4Rm-1711382217918)]

面试专题

[外链图片转存中…(img-ZFOcyenS-1711382217918)]

除了以上面试题+答案，小编同时还整理了微服务相关的实战文档也可以分享给大家学习

[外链图片转存中…(img-Ptdl1ovE-1711382217918)]

[外链图片转存中…(img-TLVWTCxS-1711382217918)]

[外链图片转存中…(img-vEx0tH3D-1711382217919)]

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

转载自CSDN-专业IT技术社区

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

原文链接：https://blog.csdn.net/m0_60147147/article/details/137029972