将字符串作为注释使用会带来多大的性能损耗？

悬浮字符串的性能损耗 #

这类无引用的字符串字面量的性能损耗几乎可以忽略，完全不会影响正常业务的运行效率，对应子问题的答案如下：

• 内存与GC表现：现代JS引擎（V8、SpiderMonkey等）在语法解析阶段就会识别到这类没有被任何变量、表达式引用的字面量，执行阶段根本不会为其分配堆内存，仅在解析流程中短暂存在后直接丢弃，完全不会触发GC流程。就算是少数不做优化的老旧引擎真的为其分配了内存，因为没有任何引用指向该字符串，下次新生代GC运行时就会被立即回收，单条字符串的内存占用仅等于自身的字节长度，就算单文件有上百条这类语句，总内存占用也不到几十KB，完全可以忽略。
• 解析成本：JS解释器确实会在词法分析阶段逐字符处理这类字符串，但处理效率极高，单条语句的解析耗时在纳秒级别，就算单文件有上百条这类语句，整体解析耗时也比不上一次普通DOM操作的千分之一，完全感知不到差异。

使用悬浮值的潜在陷阱 #

• 压缩工具误删：主流JS压缩工具（Terser、UglifyJS等）默认开启死代码消除配置，这类无副作用的悬浮字符串会被判定为无用代码直接删除，你需要额外修改压缩配置，将对应格式的字符串加入保留列表，否则打包后你的加载脚本会识别不到对应语句。
• 语法容错性低：注释内容无论写什么都不会触发语法报错，但悬浮字符串如果内容包含未转义的对应引号，就会直接抛出语法错误，比如"require("file.js")";就会因为内部双引号未转义直接报错，开发阶段的排查成本更高。
• 静态校验告警：如果你使用TypeScript、ESLint等静态校验工具，默认规则下这类无意义的表达式会触发no-unused-expressions类的告警，需要额外关闭对应规则或者加忽略标记，增加了配置成本。
• 协作语义混淆：不了解你这套规则的开发者看到悬浮字符串，大概率会误以为是漏写了赋值、调用逻辑的BUG，可能会误改或者额外加注释询问，反而增加协作成本。
• 意外执行风险：如果你的项目中有动态拼接代码执行的逻辑（eval、new Function等），悬浮字符串相比注释有更高概率被意外拼接进可执行逻辑，带来预期外的运行问题。

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