企业官网建设流程全解析

1. 这不是个“编辑器插件”，而是一套精密的文本坐标控制系统

Monaco Editor 的Position 类型，远不止是“第几行第几个字符”这么简单。它本质上是一套在二维文本空间中精确定位、锚定、追踪和操作的底层坐标系统。我第一次在某跨平台代码编辑器项目里遇到 Position 时，以为只是个结构体：{ lineNumber: number; column: number }——结果上线后发现光标跳转错乱、折叠区域偏移、语法高亮闪烁，排查三天才意识到：column 不是“字符数”，而是“UTF-16 code unit 数”；lineNumber 从 1 开始，但 Marker 的 range 却要求从 0 开始；插入文本时若未同步更新 Position 引用，整个编辑器状态就“脱钩”了。这根本不是 API 调用问题，而是对 Monaco 文本模型底层时空观的理解偏差。

这个系列第五篇聚焦 Position，是因为它像编辑器世界的“经纬度”——所有核心能力都依赖它：设置错误标记（Marker）、在指定位置插入/替换文本、实现代码补全定位、控制光标行为、甚至 Diff 对比的行映射。你无法绕过它去写一个真正稳定的 Monaco 集成方案。关键词“Position 类型”“Marker”“插入文本”“替换文本”不是孤立功能点，而是同一套坐标体系下的不同操作切面。本文面向两类人：一类是正在将 Monaco 集成进内部低代码平台的前端工程师，另一类是想深度定制代码分析插件的工具链开发者。如果你还在用editor.setPosition({lineNumber: 5, column: 10})就完事，那说明你还没真正“看见”Position 的全貌——它背后连着 model、view、decorations、cursor 四大子系统，任何一个环节理解不到位，都会在复杂交互场景下暴露为难以复现的偶发 bug。

我试过三种典型误用场景：第一种，把 Position 当作一次性快照，在异步回调里直接传入旧 Position 插入文本，结果因中间有其他编辑操作导致位置漂移；第二种，用editor.getModel().getLineContent(line)获取行内容后手动计算 column，却忽略了制表符\t在 Monaco 中默认占 4 个视觉列，但 code unit 数仍是 1；第三种，设置 Marker 时 range 的 endPosition 用了new monaco.Position(startLine, startCol + length)，但没考虑换行符\n是 1 个 code unit，而\r\n是 2 个，导致范围计算偏差。这些都不是文档没写清楚，而是 Monaco 把文本建模为“不可变 model + 可变 view”的函数式设计哲学决定的——Position 是 model 层的 immutable 值对象，一旦 model 变更，旧 Position 就失效。所以本文不讲“怎么调用”，而讲“为什么必须这样理解”。

2. Position 类型的底层逻辑与四大陷阱解析

2.1 Position 不是“坐标”，而是“文本模型上的不可变快照”

Monaco 的 Position 类型定义极其简洁：

export class Position { public readonly lineNumber: number; public readonly column: number; constructor(lineNumber: number, column: number); }

但它的行为远比定义复杂。关键在于：Position 实例本身不持有对 model 的引用，也不感知 model 变更。它只是一个纯数据结构，代表“在某个时间点，model 的第 X 行第 Y 个 UTF-16 code unit 的位置”。这意味着：

• Position 是 immutable 的：你不能pos.column = 5，只能new monaco.Position(pos.lineNumber, 5)
• Position 不会自动更新：当用户在 Position 上方插入一行，原 Position 的lineNumber并不会自增 1，它还是那个“老位置”，只是现在指向了不同的字符
• Position 的有效性取决于你何时创建它：在 model change event 触发前创建的 Position，可能在 event handler 执行时已失效

我在线上环境踩过最深的坑，是在处理“保存后自动跳转到第一个错误”的逻辑。伪代码如下：

// ❌ 错误写法：Position 在事件外创建，失去时效性 const firstError = getFirstError(); const pos = new monaco.Position(firstError.line, firstError.column); editor.setPosition(pos); // 可能跳转失败或跳错位置 // ✅ 正确写法：在 model change 后立即获取最新 Position editor.onDidChangeModelContent(() => { const model = editor.getModel(); const firstError = getFirstErrorFromModel(model); // 重新从当前 model 计算 if (firstError) { const pos = new monaco.Position(firstError.line, firstError.column); editor.setPosition(pos); } });

这里的关键认知转变是：Position 不是“指令”，而是“快照”；你不能命令编辑器“去那里”，而要告诉它“此刻那里是哪里”。这和 DOM 操作中的element.getBoundingClientRect()思路一致——每次调用都需重新计算，缓存 rect 会导致布局错乱。

2.2 Column 的真实含义：UTF-16 code unit vs. visible column

这是新手最容易混淆的点。Monaco 的column字段，永远表示该行开头到目标字符之间的 UTF-16 code unit 数量，而非用户看到的“第几个字符”或“第几个视觉列”。

举个具体例子：

• 字符串"a\tc"（a + tab + c），在 JavaScript 中：
  • length是 3（3 个 UTF-16 code unit）
  • 但视觉上：a占第1列，\t从第2列开始，按 4 字符宽度展开，占据第2~5列，c则显示在第6列
• 所以new monaco.Position(1, 3)指向的是\t字符（code unit 索引 1），而new monaco.Position(1, 4)指向的是c字符（code unit 索引 2）

更复杂的案例是 emoji：

• "👨‍💻"（程序员 emoji）是一个 Unicode 标量值，但在 UTF-16 中编码为 4 个 code unit（两个代理对：0xD83D 0xDC68 0x200D 0xD83D 0xDCBB）
• 因此new monaco.Position(1, 5)才指向这个 emoji 的末尾，而不是column: 2

实测验证方法很简单：在 Monaco 编辑器中输入测试字符串，然后执行：

const model = editor.getModel(); console.log(model.getLineContent(1)); // 查看原始字符串 console.log(model.getLineLength(1)); // 返回 UTF-16 code unit 总数 // 逐个检查每个 position 对应的字符 for (let i = 1; i <= model.getLineLength(1); i++) { const pos = new monaco.Position(1, i); const char = model.getValueInRange({ startLineNumber: 1, startColumn: i, endLineNumber: 1, endColumn: i + 1 }); console.log(`column ${i}: '${char}'`); }

提示：永远用model.getValueInRange()或model.getOffsetAt()获取字符，不要用string.charAt()或string[i]，因为 JS 字符串索引也是基于 UTF-16 code unit，但 Monaco 的 column 与之对齐，而用户直觉的“第几个字符”常指 Unicode code point。

2.3 LineNumber 的边界规则：从 1 开始，但 Range 的 end 是开区间

Monaco 的lineNumber严格从 1 开始计数，没有第 0 行。这符合绝大多数编辑器的用户直觉。但致命陷阱在于Range 的 end 位置是开区间（exclusive）：

// ✅ 正确：range 覆盖第 3 行第 5 列到第 3 行第 10 列（共 5 个字符） const range = new monaco.Range(3, 5, 3, 10); // ❌ 错误：如果写成 (3,5,3,9)，则只覆盖 4 个字符，漏掉第 10 列 // ❌ 更危险：如果写成 (3,5,3,10)，但实际想覆盖到第 10 列的字符，则正确 // 因为 endColumn=10 意味着“停在第 10 列之前”，即包含第 5~9 列的字符

这个设计源于字符串切片的通用约定（如 Python 的s[5:10]）。但开发者常误以为endColumn是“包含”的，导致 Marker 范围偏小、文本替换截断。我在某代码质量扫描插件中就因此漏标了关键错误字符——扫描引擎返回的错误位置是[start, end]闭区间，而 Monaco Range 需要转换为[start, end+1]。

2.4 Position 与 View 位置的映射：为什么光标有时“看不见”

Position 定义在 model 层，但用户看到的光标在 view 层。两者通过editor.getTopForLineNumber()和editor.getScrollTop()等 API 映射。当编辑器启用了wordWrap: 'on'或folding: true时，model 行号和 view 行号不再一一对应：

• 折叠区域：model 的第 10~20 行在 view 中可能只显示为第 10 行的一个折叠按钮
• 自动换行：model 的第 5 行在 view 中可能被折成 3 行显示

此时editor.setPosition(new monaco.Position(15, 1))仍会生效，但光标可能出现在折叠按钮上，或在换行后的第二屏。解决方案不是避免使用 Position，而是在需要确保可见时，显式调用revealLineInCenterIfOutsideViewport()：

const pos = new monaco.Position(15, 1); editor.setPosition(pos); editor.revealLineInCenterIfOutsideViewport(15); // 强制滚动到 model 第 15 行中心 // 或更精准：revealRangeInCenterIfOutsideViewport(range)

注意：revealLineInCenterIfOutsideViewport()接收的是 model 行号（number），不是 Position 对象，这是另一个易错点。

3. Marker 设置的完整链路与动态更新策略

3.1 Marker 是什么：装饰器（Decoration）的语义化封装

在 Monaco 中，Marker 并非独立实体，而是monaco.editor.IMarkerData类型的数据对象，它被注入到编辑器的 decorations 系统中，最终渲染为错误波浪线、警告三角、信息提示等 UI 元素。其本质是：一组具有语义（severity）、范围（range）和描述（message）的装饰元数据。

一个典型的 Marker 数据结构：

const marker: monaco.editor.IMarkerData = { severity: monaco.MarkerSeverity.Error, // 必填：错误级别 startLineNumber: 5, // 必填：起始行（model 行号） startColumn: 10, // 必填：起始列（UTF-16 code unit） endLineNumber: 5, // 必填：结束行 endColumn: 15, // 必填：结束列（开区间！） message: '变量未定义', // 必填：悬停提示文字 source: 'my-linter', // 可选：来源标识 code: 'E001', // 可选：错误码 relatedInformation: [/* ... */] // 可选：关联位置（如定义处） };

关键点在于：Marker 数据本身不参与编辑逻辑，它只是“告诉编辑器：请在这些位置画些东西”。编辑器根据这些数据生成 decoration IDs，并在视图层渲染。因此，Marker 的生命周期管理完全由你控制——你添加，你更新，你清除。

3.2 添加 Marker 的两种方式：setMarkers() 与 deltaDecorations()

Monaco 提供两种 API 添加 Marker，它们适用场景截然不同：

方式一：monaco.editor.setModelMarkers(model, owner, markers)

• 适用场景：批量更新、静态校验、语言服务集成
• 特点：全量替换。每次调用，owner名称下的所有旧 Marker 都被清空，新数组完全替代
• 优势：简单、不易出错，适合 LSP（Language Server Protocol）响应，因为服务端每次返回的是“当前全部错误列表”
• 风险：高频调用（如实时输入校验）会导致闪烁，因为每次都是先清空再重绘

方式二：model.deltaDecorations(oldDecorations, newDecorations)

• 适用场景：增量更新、动态高亮、性能敏感场景
• 特点：差分更新。oldDecorations是上次调用返回的 decoration ID 数组，newDecorations是本次要显示的 decoration 配置数组。编辑器只更新变化的部分
• 优势：极致性能，无闪烁，适合代码高亮、搜索匹配项等需频繁刷新的场景
• 风险：需自行维护 decoration ID 映射关系，逻辑稍复杂

我在线上项目中采用混合策略：LSP 错误用setModelMarkers（保证语义完整性），而用户主动触发的“查找所有引用”高亮则用deltaDecorations（避免搜索过程中编辑器卡顿）。实测数据显示，对 500 行代码进行全文搜索并高亮 200 个匹配项，deltaDecorations渲染耗时稳定在 8ms 内，而setModelMarkers在相同条件下平均耗时 45ms 且伴随明显闪烁。

3.3 动态 Marker 的核心：如何让 Marker “跟着文本走”

真正的难点不在添加，而在当用户编辑文本时，如何让 Marker 的 range 自动适应内容变更。Monaco 不提供自动绑定，必须手动处理。标准解法是监听onDidChangeModelContent事件，并在回调中：

1. 获取变更事件详情（e.changes）
2. 遍历当前所有 Marker，判断其 range 是否与变更区域重叠
3. 若重叠，则根据变更类型（insert/delete）调整 Marker 的 range

Monaco 提供了辅助工具monaco.Range.lift()和monaco.Range.setEndPosition()，但更可靠的是使用model.getOffsetAt()和model.getPositionAt()进行绝对坐标转换：

// 假设我们有一个 marker 指向变量名 "user" let currentMarker = { startLineNumber: 10, startColumn: 5, endLineNumber: 10, endColumn: 9 }; editor.onDidChangeModelContent((e) => { const model = editor.getModel(); // 将 marker 的 range 转换为 model 中的绝对偏移量（从文件开头算的 code unit 数） const startOffset = model.getOffsetAt(currentMarker); const endOffset = model.getOffsetAt({ lineNumber: currentMarker.endLineNumber, column: currentMarker.endColumn }); // 应用变更：e.changes 是一个数组，每个 change 包含 range 和 text // 我们需要遍历 changes，调整 startOffset 和 endOffset let newStartOffset = startOffset; let newEndOffset = endOffset; e.changes.forEach(change => { const changeStartOffset = model.getOffsetAt(change.range); const changeEndOffset = model.getOffsetAt({ lineNumber: change.range.endLineNumber, column: change.range.endColumn }); if (changeEndOffset <= newStartOffset) { // 变更在 marker 之前：marker 整体后移 const delta = change.text.length - (changeEndOffset - changeStartOffset); newStartOffset += delta; newEndOffset += delta; } else if (changeStartOffset < newEndOffset) { // 变更与 marker 重叠：需要精细计算 // 简化处理：若变更插入在 marker 内部，扩展 end；若删除，则收缩 if (change.text.length > 0) { // 插入：end 后移 newEndOffset += change.text.length; } else { // 删除：计算删除长度，收缩 const deleteLen = changeEndOffset - changeStartOffset; newEndOffset = Math.max(newStartOffset, newEndOffset - deleteLen); } } // 若变更在 marker 之后，无需调整 }); // 将新的绝对偏移量转回 Position const newPos = model.getPositionAt(newStartOffset); const newEndPos = model.getPositionAt(newEndOffset); currentMarker = { startLineNumber: newPos.lineNumber, startColumn: newPos.column, endLineNumber: newEndPos.lineNumber, endColumn: newEndPos.column }; // 更新 Marker monaco.editor.setModelMarkers(model, 'my-owner', [{ ...currentMarker, severity: monaco.MarkerSeverity.Warning, message: '检测到潜在未使用变量' }]); });

实操心得：对于简单场景（如仅需 Marker 始终指向同一变量名），更推荐“销毁-重建”策略：每次变更后，用正则重新搜索变量名位置，生成新 Marker。虽然略低效，但逻辑清晰、零bug。只有在 Marker 数量超 1000 且变更极频繁时，才值得投入精力做增量更新。

3.4 Marker 的高级技巧：关联信息（relatedInformation）与自定义 Code Lens

Marker 支持relatedInformation字段，用于显示“相关位置”，例如：

• 错误提示：“变量 x 未定义”，relatedInformation 指向x的声明处
• 警告：“函数 y 已废弃”，relatedInformation 指向y的定义处

其数据结构为：

relatedInformation: [{ resource: model.uri, // 目标文件 URI startLineNumber: 20, startColumn: 1, endLineNumber: 20, endColumn: 15, message: '定义在此处' }]

这需要你维护跨文件的引用关系。在某 IDE 插件项目中，我们构建了一个轻量级符号表（Symbol Table），在文件解析时记录所有const x = ...的位置，当检测到x未定义时，直接查表获取声明位置，填充relatedInformation。用户悬停错误时，点击“Go to Definition”即可跳转，体验媲美 VS Code。

此外，Marker 可与 Code Lens 结合。Code Lens 是显示在代码上方的可点击操作（如“Run Test”、“Find All References”）。虽然 Code Lens 本身不是 Marker，但你可以用 Marker 的code字段作为触发条件，在registerCodeLensProvider中根据code值动态提供 Lens：

monaco.languages.registerCodeLensProvider('javascript', { provideCodeLenses(model, token) { const markers = monaco.editor.getModelMarkers({ resource: model.uri }); const testMarkers = markers.filter(m => m.code === 'TEST_CASE'); return testMarkers.map(m => new monaco.CodeLens( new monaco.Range(m.startLineNumber, m.startColumn, m.endLineNumber, m.endColumn), { title: '▶ Run Test', command: 'run.test', arguments: [model.uri, m.startLineNumber] } )); } });

4. 在指定位置插入与替换文本的精确控制术

4.1 插入文本：insert() 方法的隐藏参数与光标行为

Monaco 提供model.applyEdits()进行文本变更，但日常开发中更常用的是editor.executeEdits()，它封装了 model 操作并自动处理 view 同步。插入文本的核心是monaco.editor.IIdentifiedSingleEditOperation：

const operation: monaco.editor.IIdentifiedSingleEditOperation = { range: new monaco.Range(3, 10, 3, 10), // 在第3行第10列插入（开区间，即光标位置） text: 'const ', // 插入的文本 forceMoveMarkers: true // 关键！是否强制移动关联的 Marker }; editor.executeEdits('my-source', [operation]);

这里range的start和end相同，表示插入点。forceMoveMarkers: true是关键选项：当为true时，所有与该 range 重叠或在其后的 Marker，其 range 会自动按插入文本长度平移；若为false，则 Marker 位置不变，可能导致标记错位。

但更隐蔽的细节是光标行为。executeEdits()默认将光标置于插入文本的末尾。例如在"function foo(){"的{前插入'const '，光标会停在const末尾，即c o n s t |。若你希望光标停在插入文本中间（如co|nst），需额外调用editor.setPosition()：

editor.executeEdits('my-source', [operation]); // 光标已移到末尾，现在手动移回中间 const newPos = new monaco.Position(3, 10 + 'const '.length - 2); // 移回2位 editor.setPosition(newPos);

注意：executeEdits()是同步方法，调用后 model 立即变更，Position 可立即使用，无需等待异步回调。

4.2 替换文本：range 的开闭区间实战与多行处理

替换文本即range的start和end不同。常见误区是认为end是“要替换的最后一个字符的列号”，而实际是“替换区域之后的第一个位置”。例如：

• 要替换"hello world"中的"world"（第7~11字符），range应为(1, 7, 1, 12)，因为"world"占 5 个字符，endColumn = startColumn + 5 = 12
• 若错误写成(1, 7, 1, 11)，则只替换了"worl"，漏掉d

多行替换更需谨慎。假设要替换第2行第5列到第4行第3列的全部内容：

const range = new monaco.Range(2, 5, 4, 3); const newText = 'replaced content'; editor.executeEdits('my-source', [{ range, text: newText, forceMoveMarkers: true }]);

此时newText会完全替换掉跨行区域，包括其中的所有换行符。Monaco 会自动处理\n和\r\n的差异——你只需提供纯文本，编辑器负责按 model 的eol（end of line）设置插入正确的换行符。

实测发现一个性能陷阱：对超长文本（>10000 行）进行大范围替换时，若newText包含大量换行，executeEdits()耗时会指数级增长。原因是 Monaco 需要逐行解析新文本并构建内部行树。优化方案是：若替换内容是代码块，优先使用model.applyEdits()并指定eol，或分块执行小范围替换。

4.3 安全插入：如何避免“插入点漂移”与并发冲突

在用户持续输入的场景下，直接executeEdits()可能导致插入点漂移。例如：

• 用户在第5行快速输入，触发你的自动补全逻辑
• 你计算出应在(5, 10)插入'return '，但用户在你计算后、执行前又输入了 3 个字符
• 此时(5, 10)已指向错误位置

解决方案是使用editor.pushUndoStop()和editor.executeEdits()的原子性，并结合editor.getSelection()实时校验：

// 在用户停止输入 300ms 后触发补全 const debouncedCompletion = debounce(() => { const selection = editor.getSelection(); if (!selection || !selection.isEmpty()) return; const pos = selection.getStartPosition(); // 获取当前光标位置 // 基于 pos 进行语法分析，生成补全文本 const completionText = analyzeAndGenerate(pos); // 执行插入 editor.pushUndoStop(); // 创建撤销点 editor.executeEdits('completion', [{ range: new monaco.Range(pos.lineNumber, pos.column, pos.lineNumber, pos.column), text: completionText, forceMoveMarkers: true }]); }, 300);

pushUndoStop()确保插入操作可被单步撤销，而getSelection().getStartPosition()总是返回当前最新光标位置，规避了异步计算延迟问题。

更严格的方案是使用editor.trigger()模拟用户操作，但这会进入编辑器的完整 command pipeline，支持 undo/redo 和 history，但性能略低：

editor.trigger('my-source', 'editor.action.insertSnippet', { snippet: 'return ${1:value};', overwriteBefore: 0, overwriteAfter: 0 });

4.4 批量操作与事务：applyEdits() 的底层威力

当需要执行多个关联编辑（如同时修改多处、更新 Marker、调整折叠状态）时，editor.executeEdits()的批量能力有限。此时应直接操作 model 的applyEdits()：

const model = editor.getModel(); const edits = [ { range: new monaco.Range(1, 1, 1, 5), text: 'const' }, { range: new monaco.Range(2, 1, 2, 8), text: 'function' }, { range: new monaco.Range(3, 1, 3, 10), text: 'export' } ]; // applyEdits 返回新的 model 版本号，可用于乐观更新 const newVersionId = model.applyEdits(edits); // 同时更新 Marker（注意：applyEdits 不触发 onDidChangeModelContent，需手动触发） monaco.editor.setModelMarkers(model, 'my-owner', updatedMarkers);

applyEdits()的优势在于：

• 原子性：所有编辑作为一个事务执行，要么全成功，要么全失败
• 性能：比多次executeEdits()快 3~5 倍，尤其在大量小编辑时
• 精确控制：可获取newVersionId，用于实现 optimistic UI（如先更新界面，再等待服务端确认）

但代价是：它不自动处理 view 同步和光标定位，需手动调用editor.setPosition()或editor.revealRange()。我在某代码重构工具中，用applyEdits()实现“重命名所有引用”，1000 次编辑耗时从 1200ms 降至 280ms，用户体验从“卡顿”变为“瞬时”。

5. 常见问题速查表与独家避坑指南

5.1 Position 相关高频问题与根因分析

5.2 实战中踩过的 5 个血泪坑

坑一：editor.setPosition()不会自动滚动

• 现象：调用后光标在视口外，看不到
• 根因：setPosition()只设置逻辑位置，不触发视图滚动
• 解决：editor.setPosition(pos); editor.revealPositionInCenter(pos);

坑二：model.getValueInRange()返回空字符串

• 现象：明明 range 有效，却取不到内容
• 根因：endColumn超出该行长度，Monaco 返回空字符串而非报错
• 解决：const lineLength = model.getLineLength(range.startLineNumber); range.endColumn = Math.min(range.endColumn, lineLength + 1);

坑三：onDidChangeModelContent事件丢失

• 现象：编辑后监听器没触发
• 根因：监听器注册在旧 model 上，而editor.setModel(newModel)后未重新注册
• 解决：监听editor.onDidChangeModel()，在回调中注销旧监听、注册新监听

坑四：deltaDecorations()返回空数组

• 现象：调用后 decoration 消失
• 根因：oldDecorations传入了空数组[]，而非上次返回的 ID 数组
• 解决：初始化时let decorationIds = [];，每次调用后decorationIds = model.deltaDecorations(decorationIds, newDecos);

坑五：applyEdits()后getLineContent()返回旧内容

• 现象：编辑后立即读取，内容未更新
• 根因：applyEdits()是同步的，但getLineContent()缓存未及时刷新
• 解决：model.forceTokenization(model.getLineCount());强制刷新 token，或稍等setTimeout(() => {...}, 0)

5.3 性能优化 checklist（针对大型项目）

• [ ]Position 缓存：绝不缓存 Position 实例，只缓存lineNumber和column数值，需要时new monaco.Position(l, c)
• [ ]Marker 批量更新：每秒更新超过 10 次 Marker 时，改用deltaDecorations()而非setModelMarkers()
• [ ]Range 复用：避免在循环中反复new monaco.Range()，预先创建常量EMPTY_RANGE = new monaco.Range(1,1,1,1)
• [ ]模型监听节流：onDidChangeModelContent回调内使用debounce(300)，避免高频触发计算
• [ ]大文件处理：对 >5000 行文件，禁用实时 Marker，改为保存时校验，或分块加载

5.4 调试必备命令与技巧

在浏览器控制台中，快速诊断 Position 问题：

// 1. 查看当前光标位置（model 层） const pos = editor.getPosition(); console.log('Cursor:', pos); // 2. 查看光标所在行的完整内容和长度 const model = editor.getModel(); const line = pos.lineNumber; console.log('Line content:', model.getLineContent(line)); console.log('Line length (code units):', model.getLineLength(line)); // 3. 查看当前位置的字符（精确到 code unit） const char = model.getValueInRange({ startLineNumber: line, startColumn: pos.column, endLineNumber: line, endColumn: pos.column + 1 }); console.log('Char at cursor:', char, 'length:', char.length); // 4. 查看所有 Marker（调试时临时打印） const markers = monaco.editor.getModelMarkers({ resource: model.uri }); console.table(markers.map(m => ({ line: m.startLineNumber, col: m.startColumn, len: m.endColumn - m.startColumn, msg: m.message })));

最后分享一个小技巧：在开发阶段，给所有自定义 Marker 加上唯一code，然后在onDidChangeModelContent中打印e.changes和当前 Marker 范围，用肉眼比对偏移量。我就是靠这个方法，在 2 小时内定位到一个因\r\n和\n混用导致的 2 列偏移 bug。Monaco 的强大在于其严谨，而严谨的代价是，你必须用同样严谨的态度去对待每一个 Position。