为何生成密码子MCQ选项的JS代码触发Maximum calls exceeded，同类代码却正常？

核心问题：递归终止条件的有效性差异 #

栈溢出（Maximum calls exceeded）本质是递归未正确触发终止条件，你的情况和之前数字数组生成代码的差异集中在这几点：

1. 可选元素池的大小限制 #

• 数字数组的可选范围通常极大（比如0-99甚至更大），生成不重复元素时重复概率极低，递归几次就能找到符合条件的元素，很容易触发终止逻辑。
• 但标准遗传密码表对应的常见氨基酸只有20种，加上终止密码子也没多少。如果错误选项要求「不能和正确氨基酸重复、彼此间也不重复」，当正确氨基酸之外的可选氨基酸数量不足3个时，递归会一直尝试生成新元素，永远找不到符合条件的结果，最终触发栈溢出。

2. 重复判断的逻辑复杂度 #

• 数字数组的重复判断很直接：检查数组是否包含目标数字即可，逻辑简单高效。
• 氨基酸选项的判断涉及多层映射：先从密码子映射到氨基酸，再检查错误选项数组里是否存在该氨基酸。如果映射逻辑有疏漏（比如不同密码子对应同一种氨基酸，但你误判为不同元素），或者重复判断条件写错（比如没正确排除正确选项），会导致递归误以为一直生成了重复元素，不断重复调用自身。

3. 边界场景的容错处理 #

• 数字数组生成时，你默认了「可选池足够大」的前提，递归逻辑不需要处理「无法生成足够不重复元素」的极端情况。
• 但氨基酸选项的场景必须考虑边界：当正确氨基酸之外的可选数量小于3时，你的递归没有终止分支，会无限循环调用。而数字数组场景几乎不会遇到可选池耗尽的情况，所以不会触发错误。

修复建议 #

• 提前校验错误选项池：从所有氨基酸中排除正确选项得到候选池，如果候选池长度不足3，直接抛出提示或调整题目逻辑（比如减少错误选项数量）。
• 把递归生成改成循环实现：用while循环从候选池随机选元素，直到凑够3个不重复的，避免递归带来的栈溢出风险。
• 优化重复判断：将候选池转换成Set，用has()方法判断重复，比数组includes()更高效，也能避免逻辑错误。

示例循环实现代码：

// 假设correctAmino是正确氨基酸，allAminos是所有氨基酸数组
const candidatePool = allAminos.filter(amino => amino !== correctAmino);
if (candidatePool.length < 3) {
  throw new Error("可用错误选项数量不足");
}
const wrongOptions = new Set();
while (wrongOptions.size < 3) {
  const randomIndex = Math.floor(Math.random() * candidatePool.length);
  wrongOptions.add(candidatePool[randomIndex]);
}
const finalWrongOptions = [...wrongOptions];

内容的提问来源于stack exchange，提问作者user20114922