正则表达式性能与安全优化咨询：SonarCloud告警解决方案

你的问题核心在于原正则中使用的模糊惰性匹配.*?容易引发灾难性回溯，这正是SonarCloud警告的根源——当处理较长或结构复杂的字符串时，正则引擎会尝试大量匹配路径，导致CPU耗时呈指数级增长。下面是针对两个正则的具体优化方案：

1. 优化 yearToYearWithIrrWAndDotRegex #

原正则：

const yearToYearWithIrrWAndDotRegex = /·.*?(19|20)\d{2}.*?-.*?((19|20)\d{2}|Present)?/g;

优化后：

const yearToYearWithIrrWAndDotRegex = /·\s*(?:19|20)\d{2}\s*-\s*((?:19|20)\d{2}|Present)?/g;

优化点说明： #

• 把模糊的.*?替换为精确的\s*：原目标字符串中·与年份、年份与-、-与目标年份/Present之间都是空格（或无空格），用\s*匹配任意数量的空白字符，避免了匹配无关字符带来的回溯。
• 将不需要捕获的分组改为非捕获分组(?:...)：(?:19|20)不会创建捕获组，减少正则引擎的内存开销，同时不影响匹配逻辑。

2. 优化 yearToYearRegex #

原正则：

const yearToYearRegex = /(19|20)\d{2}.*?-.*?((19|20)\d{2}|Present)/g;

优化后：

const yearToYearRegex = /(?:19|20)\d{2}\s*-\s*((?:19|20)\d{2}|Present)/g;

优化点说明： #

• 同样用\s*-\s*替换中间的.*?-.*?，精准匹配年份间的分隔符（空格+-+空格），彻底消除模糊匹配带来的回溯风险。
• 非捕获分组优化：将开头的(19|20)改为(?:19|20)，如果不需要在后续逻辑中引用这个分组的内容，非捕获分组是更高效的选择。

为什么这样优化能解决性能问题？ #

原正则中的.*?是惰性匹配，但它会匹配任意字符直到遇到下一个匹配模式，当字符串中存在多个类似·、-的字符时，正则引擎会尝试所有可能的匹配组合，导致回溯次数爆炸。而优化后的正则通过精确限定匹配内容（只匹配空白字符而非任意字符），让引擎的匹配路径变得唯一，避免了灾难性回溯，性能随输入长度线性增长，完全符合SonarCloud的性能要求。

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