回车键在嵌套 contenteditable 元素中会因事件冒泡被多层监听器捕获，导致重复换行；应监听 keydown，用 preventDefault() 阻止默认行为、stopPropagation() 阻止冒泡，并检查 e.target 是否属于当前编辑器范围。
当多个富文本编辑器（如 contenteditable 元素）存在视觉与 DOM 结构上的嵌套关系时，按回车键触发的 keydown 或 input 事件，可能因事件冒泡被多层监听器捕获，从而各自执行一次换行逻辑——结果就是：光标看似只按了一次回车，却插入了多个 <br>、多个空段落，甚至光标跳到意外位置。
这不是富文本编辑器本身的 bug，而是事件传播机制与监听方式叠加导致的典型副作用。
? 为什么回车键会“穿透”多层编辑器？
关键点在于：
- 富文本容器通常用
<div contenteditable="true">实现； - 若外层容器也设为
contenteditable，且内嵌另一个contenteditable子元素（比如悬浮菜单里的可编辑标题、嵌套卡片、引用块等），它们就构成了真实的 DOM 嵌套结构； - 当用户在最内层编辑器中按回车，
keydown事件从目标元素（如<span>或<p>）出发，逐级向上冒泡，经过所有父级contenteditable元素； - 如果每一层都绑定了
keydown监听器并判断e.key === 'Enter'，就会各自调用document.execCommand('insertLineBreak')或手动插入<br>/<p><br></p>—— 每一层都“认认真真地换了一次行”。
✅ 示例结构：
立即学习“Java免费学习笔记（深入）”；
<div contenteditable="true" class="editor-root"> <p>正文内容</p> <div contenteditable="true" class="quote-block"> <p>引用文字</p> <!-- 光标在此处按回车 --> </div> </div>此时，
quote-block和editor-root都可能响应 Enter，造成双换行。
? 如何精准拦截，只让目标编辑器处理回车？
核心原则：在事件到达父层前，明确终止冒泡，并阻止默认行为（如果需要自定义换行）。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
✅ 推荐做法（三步到位）
监听
keydown，而非input或keyupkeydown是最早可干预的时机，能有效拦截默认换行行为（如浏览器自动插入<div><br></div>）。检查事件目标是否属于当前编辑器的“可编辑内容区”
利用e.target和contains()判断是否落在本层编辑器 DOM 范围内，避免误杀。-
调用两个关键方法
e.preventDefault(); // 阻止浏览器默认换行（必须） e.stopPropagation(); // 阻止事件继续向上冒泡到父编辑器（关键！）
✅ 实际代码片段（单层编辑器内使用）
const editor = document.querySelector('.quote-block');
editor.addEventListener('keydown', function(e) {
if (e.key === 'Enter') {
e.preventDefault();
e.stopPropagation();
// 自定义换行逻辑：比如插入 <p><br></p> 或保持 inline
document.execCommand('insertParagraph', false, null);
// 或手动操作 range/selection...
}
});⚠️ 注意：若父编辑器（
.editor-root）也监听了keydown，但没加stopPropagation()，它仍会在子层处理完后收到事件——所以每一层都需独立加stopPropagation()，不能只靠最内层拦截。
? 补充提醒：别忽略 contenteditable="false" 的干扰
有时开发者试图用 contenteditable="false" 禁用父容器编辑，但：
- 它不阻止事件冒泡；
- 它不阻止
keydown被监听； - 只是让浏览器不自动聚焦或输入，事件依然照常传递。
✅ 正确做法是：对非目标区域，移除事件监听器，或用 e.target.isContentEditable === false 提前 return。
不复杂但容易忽略。
