JavaScript实现textarea选中文本格式化偶发失效问题咨询

• 关键属性误用：给textarea更新内容时错误使用了innerHTML属性。首先，textarea的可编辑文本内容的正确更新方式是操作value属性；innerHTML仅负责解析DOM结构，当拼接的格式化内容包含<u>、<sup>等带尖括号的字符串时，浏览器会自动将这些字符串解析为HTML标签插入DOM，而不是作为普通文本显示在输入框中，导致标记被直接吃掉。这也是功能“时好时坏”的核心原因：当格式化的内容（比如加粗、斜体、图片标记）不包含尖括号时，innerHTML会将其作为纯文本处理，功能正常；当格式化的内容（比如下划线、上下标）包含尖括号时，标记会被浏览器解析为DOM结构而丢失，功能异常，全程不会抛出任何脚本错误。
• 变量声明冗余混乱：函数开头已经声明了一次formatedText，在switch的每个分支内又通过var重复声明同名变量，虽然JS的函数作用域规则不会让这部分直接报错，但容易引发作用域提升带来的逻辑偏差，属于高风险坏写法。
• 缺失光标状态维护：替换文本后没有同步更新textarea的选中光标位置，会导致格式化完成后光标自动跳转到文本最开头，完全打断用户的连续输入流程。
• 边界场景缺失：没有处理未选中文本、重复点击格式化按钮的场景，会出现点击按钮后直接插入成对标记、没有可编辑内容，或者对已格式化的文本重复包裹标记、格式层层嵌套的问题。

• 基础修复：直接将赋值语句从textarea_editor.innerHTML = 拼接内容改为textarea_editor.value = 拼接内容，仅这一行修改就能解决大部分功能异常的问题——因为value属性会把所有拼接的内容都当成纯文本处理，不会解析HTML标签。
• 体验优化：
  • 抽离公共的包裹逻辑，提前维护不同格式对应的前后缀映射表，避免在每个switch分支里写重复的字符串拼接代码
  • 文本替换完成后，计算格式化内容对应的新选区范围，重新设置textarea的selectionStart和selectionEnd属性，让格式化后的文本保持选中状态，方便用户直接输入内容替换
  • 增加边界判断：如果当前没有选中文本，就自动插入成对标记并将光标定位在两个标记中间，等待用户输入；如果选中文本已经被目标格式包裹，就自动移除外层标记，实现格式切换的效果
• 关于jQuery的适配：这类基于textarea选区的格式化逻辑，核心操作依赖原生DOM的选区API，jQuery并没有提供对应的简化封装，使用jQuery不会显著减少代码量，反而因为需要从jQuery对象中取出原生DOM实例才能操作selectionStart、selectionEnd属性，增加了不必要的封装层级，性价比很低。
• 更省心的技术选型：如果需要支持更复杂的Markdown编辑能力，不需要从零开始处理不同浏览器的textarea选区兼容问题，可以直接集成经过社区验证的轻量开源Markdown编辑器组件，这类组件已经内置了加粗、斜体、图片插入等常用格式化按钮的完整逻辑，稳定性远高于自行实现的简易版本。

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