eslint-plugin-unicorn 的 comment-content 规则用--fix一键规范注释里的品牌名与大小写【免费下载链接】eslint-plugin-unicornMore than 300 powerful ESLint rules项目地址: https://gitcode.com/GitHub_Trending/es/eslint-plugin-unicorncomment-content是 eslint-plugin-unicorn 中负责注释内容质量的规则它基于内置的精选替换表自动把注释中常见的名称、品牌、缩写的大小写错误纠正为规范写法如nodejs→Node.js、github→GitHub、png→PNG并允许开发者注入自己项目专属的替换规则。本文以 docs/rules/comment-content.md 为主线结合 rules/comment-content.js 的实现与 test/comment-content.js 的用例完整讲解它的行为边界、三个配置项checkUniformCase、replacements、extendDefaultReplacements的用法以及它在源码层面的匹配与过滤原理让你能直接复制配置到自己的 ESLint 项目中。规则定位纠错型替换器而非拼写检查器规则在源码中的元信息rules/comment-content.js表明它是一条suggestion类型的规则fixable: code即可以配合 ESLint 的--fixCLI 选项自动修复修复时生成的消息为Prefer \{{replacement}} over {{value}}.消息 ID 为comment-content。同时languages: [*] 意味着它不限于 JavaScript——测试文件 test/comment-content.js 验证了它可以作用于 TOML、CSS、JSONC、HTML 与 MarkdownGFM注释。理解这条规则需要先明确几个边界来自官方文档、源码行为与测试用例三方印证它不是拼写检查器只检查已知的替换模式不会去纠正任何拼错的单词除非你把它们写进自定义replacements。每次注释只报告一处问题这是刻意设计。getReplacementProblemrules/comment-content.js在扫描替换表时只保留最早出现的那一个匹配bestProblem一旦确定就break。所以一次--fix修复一个注释里的一个问题ESLint 会反复跑多轮直到全部修复——测试fixes multiple problems in the same comment over multiple passes印证了这一点// nodejs uses javascript.需要多轮修复才能变成// Node.js uses JavaScript.。聚焦散文式注释文本明显非散文的区域会被跳过包括代码片段、被注释掉的多行代码、链接、路径、结构化数据与命令行示例。JSDoc 注释中跳过结构化标签语法参数名、类型表达式、符号引用但标签的描述性文字仍然会被检查详见下文JSDoc 结构化语法的屏蔽。基本示例三段文档原例以下三段来自官方文档的示例展示了默认行为// ❌ // nodejs uses javascript. // ✅ // Node.js uses JavaScript.// ❌ // See the github issue. // ✅ // See the GitHub issue.// ❌ // The application stores png files. // ✅ // The app stores PNG files.注意第三个例子同时演示了两种替换png→PNG是大小写修正而application→app是真正的换词字母发生变化。默认替换表百余条内置模式规则的默认替换表定义在 rules/comment-content.js包含 100 余条条目覆盖了开发者注释中最高频的名称、品牌、缩写与术语例如技术品牌eslint→ESLint、javascript→JavaScript、typescript→TypeScript、node.js/nodejs→Node.js、react.js→React、vue.js→Vue.js、github→GitHub、docker→Docker、kubernetes→Kubernetes、k8s→K8s、mysql→MySQL、postgresql→PostgreSQL、mongodb→MongoDB、redis→Redis、nginx→NGINX、vite→Vite、svelte→Svelte、deno→Deno常见缩写/技术词api→API、cli→CLI、json→JSON、yaml→YAML、xml→XML、html→HTML、css→CSS、sql→SQL、url/uri→URL/URI、uuid→UUID、svg→SVG、png/jpg/jpeg/gif/webp/avif、http/https、tcp/udp/dns、oauth→OAuth、graphql→GraphQL、websocket/webrtc/webgl等带空格的复合词stack overflow→Stack Overflow、you tube→YouTube、vs code→VS Code、mac os x/os x→macOS生态周边npm→npm、cjs/esm/umd/iife、jquery→jQuery、discord→Discord、twitch→Twitch、reddit→Reddit、facebook→Facebook。绝大多数条目都通过caseInsensitive(...)包装成大小写不敏感模式rules/comment-content.js这意味着GITHUB、Github、github都会被统一成GitHub。值得注意的实现细节是默认模式的词边界使用 Unicode 语义unicodeWordCharacterPattern [\p{Letter}\p{Mark}\p{Number}_]rules/comment-content.js即字母、组合标记、数字、下划线都被视为词的一部分。因此astérisque中的ast不会被误判为AST测试does not match default replacements inside Unicode words验证了这一点而ast—json这类紧邻 Unicode 标点的词仍能正确匹配测试matches default replacements beside Unicode punctuation。Options 配置详解规则接受一个object类型的 options对应 schema 定义 rules/comment-content.js支持以下三个键且additionalProperties: false多写的键会被 ESLint 报配置错误。checkUniformCase是否纠正全大写/全小写 token类型boolean默认值true默认情况下规则无论 token 原本是什么大小写形态都会重新套用规范写法包括全小写json与全大写JSON。传入checkUniformCase: false后只修正已经混用大小写的 token例如Github→GitHub全小写与全大写的 token 则保持原样因为这种写法往往是有意为之例如测试用例中deploy to ec2保持不动、JSON, URL, API parsing保持不动。但真正改变字母的替换不受此开关影响例如application→app或者你自己定义的错别字修正如teh→the无论大小写形态都会生效。unicorn/comment-content: [ error, { checkUniformCase: false, }, ]从源码看该开关的作用点在于isCasingOnlyChange与isMixedCaserules/comment-content.js先判断本次替换是否只是大小写变化去掉非字母数字后小写比较相等再判断被匹配的 token 是否本身混用了大小写当checkUniformCase为false且二者条件不满足时跳过该匹配rules/comment-content.js。测试文件中的checkUniformCase: false分组test/comment-content.js给出了完整的有效/无效用例对照例如// the Url of the page、// install Github cli仍会被修复而// returns json data保持不动。replacements自定义替换模式类型object通过replacements选项扩展默认替换表。键被当作正则表达式使用默认情况下自定义替换是大小写敏感的与内置模式不同内置模式大多不敏感。另外默认模式会自动把 Unicode 字母、组合标记、数字、下划线视为词的组成部分自定义模式则按你写的原样使用——所以示例中自己补上了\b词边界。unicorn/comment-content: [ error, { replacements: { \\bteh\\b: the, \\bto do\\b: { replacement: TODO, caseSensitive: false, }, \\bnode\\.?js\\b: false, }, }, ]这个示例展示了三种值的形态与 schema 中additionalProperties.anyOf一致见 rules/comment-content.js字符串\\bteh\\b: the—— 简单替换teh会被修复为the测试// teh value→// the value验证。对象{replacement: TODO, caseSensitive: false}—— 可通过caseSensitive单独控制大小写敏感性to do→TODO这个例子还说明自定义模式不限于单个单词。布尔false\\bnode\\.?js\\b: false—— 表示从替换表中删除这条规则这里是把默认的node.js/nodejs→Node.js禁用掉。源码中prepareReplacements会对replacement false的条目做filter过滤rules/comment-content.js。对象形态还允许你调整默认规则的caseSensitive。测试preserves custom replacement regex semanticstest/comment-content.js展示了对 JSDoc 中param、template、{link}等结构化语法的保护与描述性文字的修复可以共存。extendDefaultReplacements完全覆盖默认表类型boolean默认值true传入extendDefaultReplacements: false会完全丢掉内置的默认替换表只保留你replacements里定义的内容。适合那些对注释风格有强烈自定义需求、不想要任何内置规则的项目unicorn/comment-content: [ error, { extendDefaultReplacements: false, replacements: { \\bteh\\b: the, }, }, ]源码中prepareReplacements的实现rules/comment-content.js揭示了合并逻辑当extendDefaultReplacements为true时用{...defaultReplacements, ...replacements}浅合并同名键被自定义值覆盖为false时只用自定义表。这里有一个值得留意的细节如果默认模式与自定义模式同名即使extendDefaultReplacements: true该模式也不会再套用默认的 Unicode 词边界包装——因为normalizeReplacement的第三个参数isDefaultReplacement要求模式存在于默认表且未被自定义覆盖rules/comment-content.js。换言之覆盖默认模式意味着你同时接管了它的边界语义请在自己的模式里写清楚\b或改用对象形态。工作原理掩码Mask机制与多阶段跳过规则的核心思路在getSearchableCommentValuerules/comment-content.js中先把注释文本逐字符复制成数组然后用哨兵字符\uFFFF把各类非散文区域逐层掩盖再做替换匹配。掩码保持与原文一致的字符索引这样既能精确定位修复范围fixer.replaceTextRange又能防止自定义正则把被掩盖区域当作普通空白处理。整个掩盖流程依次包括maskFencedCodeBlocksMarkdown 围栏代码块maskJsdocExamplesJSDoc 的example块maskJSDocumentSyntax仅 JSDoc 注释标签语法、参数名、类型表达式与{link}等行内符号引用——实现在 rules/utils/jsdoc.js描述性文字保留检查maskIgnoredLines逐行识别代码样行import/export/const/return、控制流、成员访问、函数调用、shell 提示符行、key: value结构化行等并用括号深度状态机把被注释掉的多行代码的续行也一并掩盖rules/comment-content.jsmaskInlineCodeAndQuotedStrings行内代码反引号与引号字符串urlPattern、maskBareDomains裸域名如github.com、mimeTypePattern如application/json、maskPackageSpecifiersnpm 包名如typescript-eslint/types、maskMarkdownLinks、maskMarkupTags。在替换执行阶段还有一层匹配局部检查shouldSkipMatchrules/comment-content.js如果匹配点紧邻路径分隔符、属于属性访问foo.api、前面/后面是连字符复合词片段如foo-github-bar或后面紧跟(如React.js()则跳过。测试中// foo.github and github docs只修后者、// The file is api.js.不报错都印证了这些边界。性能优化方面源码针对默认模式做了字面前缀预检literalPrefixPattern与getRequiredText见 rules/comment-content.js大多数模式以字面单词开头先用String#includes廉价地判断注释里是否存在必要文本不存在就跳过整个正则只有模式含顶层|或带量词等无法预检的情况才直接跑正则。另外还合并了所有全大写缩写词条为一个 alternation 正则defaultReplacementTermPattern用来识别ci/cd、ui/ux这类斜杠分隔的散文对见isSlashPairProse与测试fixes slash-separated acronym pairs。跨语言与 Markdown 支持测试用例给出的证据规则声明的languages: [*]不是空话test/comment-content.js 用语言插件逐一验证了各语言下的行为TOML# github→# GitHub且字符串值# nodejs不被误改CSS/* nodejs */→/* Node.js */JSONC行注释被修复url: nodejs字符串保持不动HTML!-- github --→!-- GitHub --MarkdownGFMHTML 注释!-- github --被修复而// github这种非 HTML 注释的正文、以及围栏代码块内的!-- github --都被忽略测试ignores Markdown fenced code block content。为支撑 Markdown 场景规则在.md/.markdown文件中会额外用getMarkdownHtmlCommentsrules/comment-content.js从原始文本中手工提取!-- ... --注释同时通过normalizeCommentrules/utils/normalize-comment.js把 JSON 等语言中以 token 形式暴露、缺少value的注释规整成 JS 形状的Line/Block注释。与配置的关系与启用方式按官方文档说明本规则在recommended与unopinionated两个预设配置中都是默认关闭的源码注释也写明 TODO: Add back torecommendedonce the rule is more maturerules/comment-content.js需要在项目里显式开启// eslint.config.jsflat config export default [ { plugins: { unicorn: require(eslint-plugin-unicorn), }, rules: { unicorn/comment-content: [ error, { // checkUniformCase: false, // 只修混用大小写的 token // extendDefaultReplacements: false, // 完全使用自定义表 // replacements: { // \\bteh\\b: the, // 自定义错别字修复 // }, }, ], }, }, ];配置完成后运行npx eslint --fix .即可自动完成所有注释替换由于每条注释每次只报一个替换遇到同一条注释里存在多处问题时--fix会自动多轮迭代直到稳定测试fixes multiple problems in the same comment over multiple passes已证明该收敛行为。小结comment-content是一个定位清晰、实现精细的注释内容规则它不试图读懂自然语言而是用一张可扩展的精选替换表加一套严谨的非散文区域掩码机制在自动修复注释中品牌名与缩写大小写的同时绝不误伤代码片段、路径、链接、包名与 JSDoc 结构化语法。对团队而言把品牌、产品名、术语的规范写法固化进replacements配合extendDefaultReplacements: false打造项目专属的注释风格是一条低成本、高收益的代码规范落地方式。相关资源规则实现rules/comment-content.js规则文档docs/rules/comment-content.md测试用例含各语言与边界行为test/comment-content.js依赖工具rules/utils/jsdoc.js、rules/utils/normalize-comment.js、rules/utils/get-comments.js、rules/utils/on-root.js【免费下载链接】eslint-plugin-unicornMore than 300 powerful ESLint rules项目地址: https://gitcode.com/GitHub_Trending/es/eslint-plugin-unicorn创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/18 1:38:59 · 阅读 1.2k eslint-plugin-unicorn 的 comment-content 规则：用 `--fix` 一键规范注释里的品牌名与大小写
eslint-plugin-unicorn 的 comment-content 规则用--fix一键规范注释里的品牌名与大小写【免费下载链接】eslint-plugin-unicornMore than 300 powerful ESLint rules项目地址: https://gitcode.com/GitHub_Trending/es/eslint-plugin-unicorncomment-content是 eslint-plugin-unicorn 中负责注释内容质量的规则它基于内置的精选替换表自动把注释中常见的名称、品牌、缩写的大小写错误纠正为规范写法如nodejs→Node.js、github→GitHub、png→PNG并允许开发者注入自己项目专属的替换规则。本文以 docs/rules/comment-content.md 为主线结合 rules/comment-content.js 的实现与 test/comment-content.js 的用例完整讲解它的行为边界、三个配置项checkUniformCase、replacements、extendDefaultReplacements的用法以及它在源码层面的匹配与过滤原理让你能直接复制配置到自己的 ESLint 项目中。规则定位纠错型替换器而非拼写检查器规则在源码中的元信息rules/comment-content.js表明它是一条suggestion类型的规则fixable: code即可以配合 ESLint 的--fixCLI 选项自动修复修复时生成的消息为Prefer \{{replacement}} over {{value}}.消息 ID 为comment-content。同时languages: [*] 意味着它不限于 JavaScript——测试文件 test/comment-content.js 验证了它可以作用于 TOML、CSS、JSONC、HTML 与 MarkdownGFM注释。理解这条规则需要先明确几个边界来自官方文档、源码行为与测试用例三方印证它不是拼写检查器只检查已知的替换模式不会去纠正任何拼错的单词除非你把它们写进自定义replacements。每次注释只报告一处问题这是刻意设计。getReplacementProblemrules/comment-content.js在扫描替换表时只保留最早出现的那一个匹配bestProblem一旦确定就break。所以一次--fix修复一个注释里的一个问题ESLint 会反复跑多轮直到全部修复——测试fixes multiple problems in the same comment over multiple passes印证了这一点// nodejs uses javascript.需要多轮修复才能变成// Node.js uses JavaScript.。聚焦散文式注释文本明显非散文的区域会被跳过包括代码片段、被注释掉的多行代码、链接、路径、结构化数据与命令行示例。JSDoc 注释中跳过结构化标签语法参数名、类型表达式、符号引用但标签的描述性文字仍然会被检查详见下文JSDoc 结构化语法的屏蔽。基本示例三段文档原例以下三段来自官方文档的示例展示了默认行为// ❌ // nodejs uses javascript. // ✅ // Node.js uses JavaScript.// ❌ // See the github issue. // ✅ // See the GitHub issue.// ❌ // The application stores png files. // ✅ // The app stores PNG files.注意第三个例子同时演示了两种替换png→PNG是大小写修正而application→app是真正的换词字母发生变化。默认替换表百余条内置模式规则的默认替换表定义在 rules/comment-content.js包含 100 余条条目覆盖了开发者注释中最高频的名称、品牌、缩写与术语例如技术品牌eslint→ESLint、javascript→JavaScript、typescript→TypeScript、node.js/nodejs→Node.js、react.js→React、vue.js→Vue.js、github→GitHub、docker→Docker、kubernetes→Kubernetes、k8s→K8s、mysql→MySQL、postgresql→PostgreSQL、mongodb→MongoDB、redis→Redis、nginx→NGINX、vite→Vite、svelte→Svelte、deno→Deno常见缩写/技术词api→API、cli→CLI、json→JSON、yaml→YAML、xml→XML、html→HTML、css→CSS、sql→SQL、url/uri→URL/URI、uuid→UUID、svg→SVG、png/jpg/jpeg/gif/webp/avif、http/https、tcp/udp/dns、oauth→OAuth、graphql→GraphQL、websocket/webrtc/webgl等带空格的复合词stack overflow→Stack Overflow、you tube→YouTube、vs code→VS Code、mac os x/os x→macOS生态周边npm→npm、cjs/esm/umd/iife、jquery→jQuery、discord→Discord、twitch→Twitch、reddit→Reddit、facebook→Facebook。绝大多数条目都通过caseInsensitive(...)包装成大小写不敏感模式rules/comment-content.js这意味着GITHUB、Github、github都会被统一成GitHub。值得注意的实现细节是默认模式的词边界使用 Unicode 语义unicodeWordCharacterPattern [\p{Letter}\p{Mark}\p{Number}_]rules/comment-content.js即字母、组合标记、数字、下划线都被视为词的一部分。因此astérisque中的ast不会被误判为AST测试does not match default replacements inside Unicode words验证了这一点而ast—json这类紧邻 Unicode 标点的词仍能正确匹配测试matches default replacements beside Unicode punctuation。Options 配置详解规则接受一个object类型的 options对应 schema 定义 rules/comment-content.js支持以下三个键且additionalProperties: false多写的键会被 ESLint 报配置错误。checkUniformCase是否纠正全大写/全小写 token类型boolean默认值true默认情况下规则无论 token 原本是什么大小写形态都会重新套用规范写法包括全小写json与全大写JSON。传入checkUniformCase: false后只修正已经混用大小写的 token例如Github→GitHub全小写与全大写的 token 则保持原样因为这种写法往往是有意为之例如测试用例中deploy to ec2保持不动、JSON, URL, API parsing保持不动。但真正改变字母的替换不受此开关影响例如application→app或者你自己定义的错别字修正如teh→the无论大小写形态都会生效。unicorn/comment-content: [ error, { checkUniformCase: false, }, ]从源码看该开关的作用点在于isCasingOnlyChange与isMixedCaserules/comment-content.js先判断本次替换是否只是大小写变化去掉非字母数字后小写比较相等再判断被匹配的 token 是否本身混用了大小写当checkUniformCase为false且二者条件不满足时跳过该匹配rules/comment-content.js。测试文件中的checkUniformCase: false分组test/comment-content.js给出了完整的有效/无效用例对照例如// the Url of the page、// install Github cli仍会被修复而// returns json data保持不动。replacements自定义替换模式类型object通过replacements选项扩展默认替换表。键被当作正则表达式使用默认情况下自定义替换是大小写敏感的与内置模式不同内置模式大多不敏感。另外默认模式会自动把 Unicode 字母、组合标记、数字、下划线视为词的组成部分自定义模式则按你写的原样使用——所以示例中自己补上了\b词边界。unicorn/comment-content: [ error, { replacements: { \\bteh\\b: the, \\bto do\\b: { replacement: TODO, caseSensitive: false, }, \\bnode\\.?js\\b: false, }, }, ]这个示例展示了三种值的形态与 schema 中additionalProperties.anyOf一致见 rules/comment-content.js字符串\\bteh\\b: the—— 简单替换teh会被修复为the测试// teh value→// the value验证。对象{replacement: TODO, caseSensitive: false}—— 可通过caseSensitive单独控制大小写敏感性to do→TODO这个例子还说明自定义模式不限于单个单词。布尔false\\bnode\\.?js\\b: false—— 表示从替换表中删除这条规则这里是把默认的node.js/nodejs→Node.js禁用掉。源码中prepareReplacements会对replacement false的条目做filter过滤rules/comment-content.js。对象形态还允许你调整默认规则的caseSensitive。测试preserves custom replacement regex semanticstest/comment-content.js展示了对 JSDoc 中param、template、{link}等结构化语法的保护与描述性文字的修复可以共存。extendDefaultReplacements完全覆盖默认表类型boolean默认值true传入extendDefaultReplacements: false会完全丢掉内置的默认替换表只保留你replacements里定义的内容。适合那些对注释风格有强烈自定义需求、不想要任何内置规则的项目unicorn/comment-content: [ error, { extendDefaultReplacements: false, replacements: { \\bteh\\b: the, }, }, ]源码中prepareReplacements的实现rules/comment-content.js揭示了合并逻辑当extendDefaultReplacements为true时用{...defaultReplacements, ...replacements}浅合并同名键被自定义值覆盖为false时只用自定义表。这里有一个值得留意的细节如果默认模式与自定义模式同名即使extendDefaultReplacements: true该模式也不会再套用默认的 Unicode 词边界包装——因为normalizeReplacement的第三个参数isDefaultReplacement要求模式存在于默认表且未被自定义覆盖rules/comment-content.js。换言之覆盖默认模式意味着你同时接管了它的边界语义请在自己的模式里写清楚\b或改用对象形态。工作原理掩码Mask机制与多阶段跳过规则的核心思路在getSearchableCommentValuerules/comment-content.js中先把注释文本逐字符复制成数组然后用哨兵字符\uFFFF把各类非散文区域逐层掩盖再做替换匹配。掩码保持与原文一致的字符索引这样既能精确定位修复范围fixer.replaceTextRange又能防止自定义正则把被掩盖区域当作普通空白处理。整个掩盖流程依次包括maskFencedCodeBlocksMarkdown 围栏代码块maskJsdocExamplesJSDoc 的example块maskJSDocumentSyntax仅 JSDoc 注释标签语法、参数名、类型表达式与{link}等行内符号引用——实现在 rules/utils/jsdoc.js描述性文字保留检查maskIgnoredLines逐行识别代码样行import/export/const/return、控制流、成员访问、函数调用、shell 提示符行、key: value结构化行等并用括号深度状态机把被注释掉的多行代码的续行也一并掩盖rules/comment-content.jsmaskInlineCodeAndQuotedStrings行内代码反引号与引号字符串urlPattern、maskBareDomains裸域名如github.com、mimeTypePattern如application/json、maskPackageSpecifiersnpm 包名如typescript-eslint/types、maskMarkdownLinks、maskMarkupTags。在替换执行阶段还有一层匹配局部检查shouldSkipMatchrules/comment-content.js如果匹配点紧邻路径分隔符、属于属性访问foo.api、前面/后面是连字符复合词片段如foo-github-bar或后面紧跟(如React.js()则跳过。测试中// foo.github and github docs只修后者、// The file is api.js.不报错都印证了这些边界。性能优化方面源码针对默认模式做了字面前缀预检literalPrefixPattern与getRequiredText见 rules/comment-content.js大多数模式以字面单词开头先用String#includes廉价地判断注释里是否存在必要文本不存在就跳过整个正则只有模式含顶层|或带量词等无法预检的情况才直接跑正则。另外还合并了所有全大写缩写词条为一个 alternation 正则defaultReplacementTermPattern用来识别ci/cd、ui/ux这类斜杠分隔的散文对见isSlashPairProse与测试fixes slash-separated acronym pairs。跨语言与 Markdown 支持测试用例给出的证据规则声明的languages: [*]不是空话test/comment-content.js 用语言插件逐一验证了各语言下的行为TOML# github→# GitHub且字符串值# nodejs不被误改CSS/* nodejs */→/* Node.js */JSONC行注释被修复url: nodejs字符串保持不动HTML!-- github --→!-- GitHub --MarkdownGFMHTML 注释!-- github --被修复而// github这种非 HTML 注释的正文、以及围栏代码块内的!-- github --都被忽略测试ignores Markdown fenced code block content。为支撑 Markdown 场景规则在.md/.markdown文件中会额外用getMarkdownHtmlCommentsrules/comment-content.js从原始文本中手工提取!-- ... --注释同时通过normalizeCommentrules/utils/normalize-comment.js把 JSON 等语言中以 token 形式暴露、缺少value的注释规整成 JS 形状的Line/Block注释。与配置的关系与启用方式按官方文档说明本规则在recommended与unopinionated两个预设配置中都是默认关闭的源码注释也写明 TODO: Add back torecommendedonce the rule is more maturerules/comment-content.js需要在项目里显式开启// eslint.config.jsflat config export default [ { plugins: { unicorn: require(eslint-plugin-unicorn), }, rules: { unicorn/comment-content: [ error, { // checkUniformCase: false, // 只修混用大小写的 token // extendDefaultReplacements: false, // 完全使用自定义表 // replacements: { // \\bteh\\b: the, // 自定义错别字修复 // }, }, ], }, }, ];配置完成后运行npx eslint --fix .即可自动完成所有注释替换由于每条注释每次只报一个替换遇到同一条注释里存在多处问题时--fix会自动多轮迭代直到稳定测试fixes multiple problems in the same comment over multiple passes已证明该收敛行为。小结comment-content是一个定位清晰、实现精细的注释内容规则它不试图读懂自然语言而是用一张可扩展的精选替换表加一套严谨的非散文区域掩码机制在自动修复注释中品牌名与缩写大小写的同时绝不误伤代码片段、路径、链接、包名与 JSDoc 结构化语法。对团队而言把品牌、产品名、术语的规范写法固化进replacements配合extendDefaultReplacements: false打造项目专属的注释风格是一条低成本、高收益的代码规范落地方式。相关资源规则实现rules/comment-content.js规则文档docs/rules/comment-content.md测试用例含各语言与边界行为test/comment-content.js依赖工具rules/utils/jsdoc.js、rules/utils/normalize-comment.js、rules/utils/get-comments.js、rules/utils/on-root.js【免费下载链接】eslint-plugin-unicornMore than 300 powerful ESLint rules项目地址: https://gitcode.com/GitHub_Trending/es/eslint-plugin-unicorn创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考