简介：面向C#开发者的文本/代码编辑器源码解析文档，以WinForm+RichTextBox为主线，讲解字体加粗/斜体/下划线切换、对齐与颜色设置，以及OpenFileDialog/SaveFileDialog实现文件读写、状态栏实时更新和try-catch异常处理等基础编辑功能；同时梳理RoslynPad、Notepads、DownmarkerWPF三款开源编辑器的特性、适用场景与GitHub地址，并探讨语法高亮、RTF/HTML格式扩展、插件系统与项目管理等进阶方向，适合希望从零构建编辑器或基于开源项目二次开发的研发人员。资源为单个docx文档，共1份文件，压缩包仅18KB，属于思路梳理与源码导读类轻量资料，便于通读和反复查阅。目前已有234人浏览学习，内容还提供CSDN文库与GitHub优质项目的获取指引，以及System.IO文件流操作、事件驱动编程等开发技巧，可帮助读者掌握基础实现后快速定位适合自己的深入学习路径。
1. 从零手写 WinForm 文本编辑器：看似是入门作业，其实是桌面开发的完整体检
如果你以为“基于 WinForm 的文本编辑器”只是拖一个文本框、加两个按钮的入门作业，那大概率会在第一轮功能扩展时被迫返工。真正把一个编辑器从“能打字”推到“能干活”，背后涉及控件选型、文档状态管理、命令撤销、文件编码、拖放协议、UI 线程调度这一整条链路——这些恰恰是 C# 桌面开发里最容易踩坑、又最不缺玄学的地方。这篇笔记会沿着源码层拆解一个基础编辑器的最小骨架，再一步步把撤销重做、查找替换、拖放编辑、编码检测、语法高亮等高级特性补上去。适读人群是两类：正在用 WinForm 写内部工具、想把代码从“一次脚本”升级成“可持续维护的小产品”的工程师，以及刚学完 C# 语法、想找一个真实项目练手但又不愿停留在“按钮 + 事件”层面的入门者。
2. 源码解剖：WinForm 编辑器的骨架是如何组装起来的
2.1 先选对文本控件的底座：TextBox 与 RichTextBox 的差异决定了你的扩展天花板
很多人一上来就拖一个 TextBox，理由是“简单”。可当你做到查找高亮、行号、撤销粒度控制时，TextBox 会像个跛脚运动员——它根本不暴露文本区域的绘制接口，也不提供 SelectionChange 之外的细粒度事件。我一般会直接选 RichTextBox 做底座，不是贪它自带加粗斜体，而是因为它把文本容器和格式化模型解耦，扩展面大得多。
选 RichTextBox 的第二个理由是它的内置撤销栈是可干预的，而 TextBox 的撤销基本是黑匣子。对于文本编辑器这个场景，“撤销栈”不是锦上添花，是用户默认会用的底线操作。所以源码解析第一步要做的，是先把控件属性调到适合“文档编辑”的状态，而不是默认的“聊天输入框”状态。下面是一个初始化块，我通常在窗体构造函数里调用：
private void ConfigureEditorCore(RichTextBox editor) { editor.Dock = DockStyle.Fill; editor.BorderStyle = BorderStyle.None; editor.HideSelection = false; editor.AcceptsTab = true; editor.DetectUrls = false; editor.WordWrap = false; editor.ScrollBars = RichTextBoxScrollBars.Both; editor.MaxLength = 0; // 0 表示不限制长度 editor.ShortcutsEnabled = true; editor.EnableAutoDragDrop = false; // 拖放文件走自定义逻辑 }这段配置的用意要拆开讲。AcceptsTab = true表示让 Tab 键直接把制表符送进文本而不是切换焦点——对写代码或写配置文件的人来说这是刚需。DetectUrls = false是关掉控件的自动 URL 识别，否则你粘一串路径进去它会擅自加下划线，后续做自定义高亮时会造成样式冲突。EnableAutoDragDrop = false同样重要：控件默认的 OLE 拖放只处理文本，我们要做的是把外部文件拖进来打开，所以要在后面自己接管 DragDrop 事件链。WordWrap = false则是让横向滚动条接管长行，很多编辑器最初的翻车现场就始于“长行被自动换行后行号对不齐”。
2.2 把源码拆开来看：新建、打开、保存的最小闭环怎么才不留死角
文本编辑器的文件操作看起来简单：打开就是读文件、保存就是写文件。但把它放到 WinForm 上下文里，至少要解决三个问题：文件是否已经存在且被外部程序占用、文本编码怎么识别、以及“未保存的修改”如何不被静默丢弃。先看打开和新建的最小实现：
public bool NewDocument() { if (!ConfirmSaveIfDirty()) return false; editor.Clear(); _currentFilePath = null; _dirtyFlag = false; UpdateCaption(); return true; } public bool OpenDocument(string filePath) { if (!ConfirmSaveIfDirty()) return false; try { using (var stream = new FileStream(filePath, FileMode.Open, FileAccess.Read, FileShare.ReadWrite)) using (var reader = new StreamReader(stream, DetectEncoding(stream), true)) { editor.Text = reader.ReadToEnd(); _currentFilePath = filePath; _dirtyFlag = false; editor.SelectionStart = 0; editor.ScrollToCaret(); UpdateCaption(); return true; } } catch (Exception ex) { MessageBox.Show($"打开文件失败：{ex.Message}", "错误", MessageBoxButtons.OK, MessageBoxIcon.Error); return false; } }这里的几个设计点是源码解析的重点。ConfirmSaveIfDirty()是第一个关键——每次 New/Open 之前必须拦住未保存的修改，这是桌面编辑器的基本卫生习惯，很多人忽略它，直到用户误点新建丢了一天的工作。FileShare.ReadWrite是第二个关键：默认的 FileShare.Read 会把其他进程的写入请求拒之门外，而你用记事本打开一个日志文件时，往往希望别的程序继续写它。DetectEncoding(stream)是第三个关键，只读前若干字节做 BOM 嗅探，避免 UTF-8 带 BOM 的文件显示成乱码，这一节会放到后面编码检测部分详细展开。
保存的对称实现同样要处理“另存为”与“原路径保存”的分叉：
public bool SaveDocument() { if (string.IsNullOrEmpty(_currentFilePath)) return SaveAsDocument(); return WriteToFile(_currentFilePath); } public bool SaveAsDocument() { using (var dlg = new SaveFileDialog()) { dlg.Filter = "文本文件 (*.txt)|*.txt|所有文件 (*.*)|*.*"; dlg.DefaultExt = "txt"; dlg.AddExtension = true; if (dlg.ShowDialog() != DialogResult.OK) return false; return WriteToFile(dlg.FileName); } } private bool WriteToFile(string path) { try { // 保留原来的编码：若文件原本是 GBK，不应默认存成 UTF-8 var encoding = _detectedEncoding ?? Encoding.UTF8; using (var writer = new StreamWriter(path, false, encoding)) { writer.Write(editor.Text); } _currentFilePath = path; _dirtyFlag = false; UpdateCaption(); return true; } catch (Exception ex) { MessageBox.Show($"保存文件失败：{ex.Message}", "错误", MessageBoxButtons.OK, MessageBoxIcon.Error); return false; } }保存时最常见的错误是“一律用 UTF-8 覆盖”。如果你打开的是一个 GB2312 编码的老配置文件，编辑完再存成 UTF-8，下游程序可能就解析乱码了。所以我在打开文件时把检测到的编码存进_detectedEncoding，保存时优先复用。StreamWriter 的第二个参数false表示不追加、直接覆盖，这里必须写清楚，否则默认行为会把你吓一跳。另外AddExtension = true配合DefaultExt = "txt"是为了让用户在另存为时输入myfile得到myfile.txt，而不是不带后缀的文件。
2.3 用“脏标记”管理未保存状态，让用户不再误丢内容
WinForm 的 TextChanged 事件是一个高频入口，但它有个特性：每次文本变化都会触发，包括程序自己赋值editor.Text = ...的时候。如果你在OpenDocument方法里改了editor.Text，紧接着事件里就把_dirtyFlag置真，那么打开一个文件后系统会误以为内容被修改过。这是文本编辑器源码解析里最不值得踩的坑，解决办法是利用一个_isInternalChange开关：
private bool _isInternalChange = false; private void Editor_TextChanged(object sender, EventArgs e) { if (_isInternalChange) return; _dirtyFlag = true; UpdateCaption(); } private void SetEditorTextInternal(string text) { _isInternalChange = true; editor.Text = text; _isInternalChange = false; }这样一个开关就把“程序主动赋值”和“用户输入”两种来源区分开了。UpdateCaption()里配合标题栏文本变化——通常会显示文件名.txt - 已修改这样的可感知状态。Flaggable 的脏机制另一层价值在于：窗口关闭事件、打开新文件、退出程序前都能统一调用ConfirmSaveIfDirty()，把未保存的修改拦截下来。很多人问“为什么我的窗口关闭时没有提示”，本质就是没有把脏标记扩散到所有需要拦截的路径上，只拦了窗体的 FormClosing 事件，却漏了打开文件这件同样会丢数据的事。
3. 高级编辑特性：撤销重做、查找替换与拖放的真实实现路径
3.1 撤销/重做：依赖控件的内置栈，还是自建命令栈？
先给结论：如果你的编辑器只需要“撤销键入、撤销删除”这种粒度，直接使用 RichTextBox 内置的 Undo/Redo 就足够，别再重复造轮子。但当你要做“批量替换操作可以被一步撤销”，内置 Undo 就会失效——批量替换是通过多次文本赋值完成的，控件会把每一次赋值都当成独立步骤。这时有两种解法。
解法一：在批量替换前后关闭控件的事件，调用editor.SuspendLayout()和editor.Text = ...后清理一次撤销栈。这种做法粗暴但有效，适合替换次数少、文本体量小的场景。解法二：自建命令栈，把一次替换封装成一个命令对象，内部记录替换前后的文本快照：
public interface IEditorCommand { void Execute(); void Undo(); } public class ReplaceAllCommand : IEditorCommand { private readonly RichTextBox _editor; private readonly string _oldText; private readonly string _newText; private readonly int _start; private readonly int _length; public ReplaceAllCommand(RichTextBox editor, string oldText, string newText, int start, int length) { _editor = editor; _oldText = oldText; _newText = newText; _start = start; _length = length; } public void Execute() { var savedStart = _editor.SelectionStart; _editor.Select(_start, _length); _editor.SelectedText = _newText; _editor.SelectionStart = savedStart; } public void Undo() { var savedStart = _editor.SelectionStart; _editor.Select(_start, _newText.Length); _editor.SelectedText = _oldText; _editor.SelectionStart = savedStart; } }这个命令模式的价值不只是“能撤销”，而是让你把一次功能操作变成可组合的单元。以后要支持多级撤销、批量操作合并、甚至把操作录制为宏，都建立在命令对象之上。自定义命令栈需要注意一个细节：SelectionStart和SelectionLength必须在修改后有选择性地恢复，否则用户替换完文本，光标位置会跳回开头，体验很差。但也不要完全用ScrollToCaret()——它会强行滚动视口，连续替换多个区域时屏幕会跳动得让人头晕。折中做法是只恢复SelectionStart，不主动滚动视口。
3.2 查找替换：高亮命中区域与处理重叠匹配的两个边界
查找替换看起来是编辑器最简单的功能，但实现得不好的话，用户反馈会是“这个查找是智障吗”。常见问题包括：大小写敏感不区分、不支持整词匹配、连续查找时定位逻辑出错。建议直接提供Regex作为检索后端，配合一个可切换的RegexOptions：
public IEnumerable<Range> FindMatches(RichTextBox editor, string pattern, bool matchCase, bool wholeWord) { var options = RegexOptions.None; if (!matchCase) options |= RegexOptions.IgnoreCase; var regex = new Regex(BuildSearchPattern(pattern, wholeWord), options); foreach (Match m in regex.Matches(editor.Text)) { yield return new Range(m.Index, m.Length); } } private string BuildSearchPattern(string userText, bool wholeWord) { var escaped = Regex.Escape(userText); return wholeWord ? $@"\b{escaped}\b" : escaped; }两个边界值得单独强调。第一个是重叠匹配：用正则Matches()方法时，它默认是“非重叠”扫描，这个行为符合查找直觉，不必改。第二个是你的替换操作会改变文本中后续匹配项的位置坐标。如果先用Matches()拿到全部位置，再按坐标逐一替换，前一次替换会让后面的位置整体偏移。破解办法是：要么从文本尾部向前替换，要么每替换一次重新计算后续匹配。我采用的做法是分组替换：把一次替换拆成多次正向查找-定位-替换，每一次都从上次替换的结束索引之后继续查找。
public int ReplaceAll(string pattern, string replacement, bool matchCase) { var count = 0; var startIndex = 0; var options = matchCase ? RegexOptions.None : RegexOptions.IgnoreCase; while (true) { var m = Regex.Match(editor.Text, pattern, options, TimeSpan.FromMilliseconds(200)); if (!m.Success) break; editor.Select(m.Index, m.Length); editor.SelectedText = replacement; count++; startIndex = m.Index + replacement.Length; } return count; }这里用TimeSpan.FromMilliseconds(200)给正则加超时是必要的防护——如果用户搜索的 pattern 触发灾难性回溯，没有超时会直接让 UI 线程假死。查找方向为反向时，同样需要把起点放在“当前光标之前”，并且匹配成功后把光标定位到命中的开头而不是结尾，这样按下“查找上一个”时视角更自然。
3.3 拖放编辑与多文档：用 DragDrop 接住外部文件，用 TabControl 切换上下文
拖放文件进窗口就直接打开，这是用户对桌面编辑器的一个“本能使唤”。WinForm 控件默认只允许从内部拖拽文本，要接住来自资源管理器的文件，必须手动接管几个事件。代码框架如下：
private void Editor_DragEnter(object sender, DragEventArgs e) { if (e.Data.GetDataPresent(DataFormats.FileDrop)) e.Effect = DragDropEffects.Copy; else e.Effect = DragDropEffects.None; } private void Editor_DragDrop(object sender, DragEventArgs e) { if (e.Data.GetDataPresent(DataFormats.FileDrop)) { var files = (string[])e.Data.GetData(DataFormats.FileDrop); if (files.Length > 0) { OpenDocument(files[0]); // 多个文件时可逐个打开到新 Tab } } }这段代码的另一个用途是和TabControl集成：当应用支持一次打开多个文件时，每个文件对应一个 TabPage，DragDrop在 TabControl 上时打开到新 Tab，在编辑区上时覆盖当前文档。要注意e.Data.GetData(DataFormats.FileDrop)返回的是string[]，不要直接当成单个字符串处理。每次拖放落地后还会触发DragLeave，如果不做清理，拖拽经过窗口时会出现目标效果残留。
4. WinForm 编辑器避坑指南：5 个最容易翻车的现场与排查步骤
4.1 现象：打开 20MB 以上的文本文件，窗口直接“未响应”，连关闭都费劲
原因：ReadToEnd()和editor.Text = text都在 UI 线程上同步执行，大文件读取与重新布局都会阻塞消息循环，界面自然假死。解决分两步。第一步，把读取放进后台线程，但RichTextBox.Text必须在 UI 线程赋值，于是要用BeginInvoke归还控制权；第二，如果文件达到几十 MB 以上，RichTextBox本身就不再是合适的容器了，应该切换到支持虚拟模式的文本视图模型——但那是另一个工程，这里我们先处理可接受范围内的文件：
private async void OpenLargeDocumentAsync(string filePath) { _isInternalChange = true; editor.Text = "正在加载..."; _isInternalChange = false; var content = await Task.Run(() => { using var stream = new FileStream(filePath, FileMode.Open, FileAccess.Read, FileShare.ReadWrite); using var reader = new StreamReader(stream, DetectEncoding(stream), true); return reader.ReadToEnd(); }); editor.Text = content; editor.SelectionStart = 0; editor.ScrollToCaret(); }要注意的是async void只用于事件处理器，普通方法切忌返回 void。第二点是加载期间界面要给出明确提示，而不是把文本框置空——用户会以为文件被清空。如果读取发生在后台而用户在此期间又键入文字，返回后editor.Text = content会把输入冲掉，所以加载完成前应禁用编辑框，或在加载前先记录用户是否已输入并给出冲突提示。
4.2 现象：Win10/Win11 下输入中文时，候选框跟着滚动条一起跳动，甚至候选词显示不出来
原因：RichTextBox 与输入法编辑器（IME）的窗口协作在某些系统版本上有兼容问题。控件滚动时 IME 组合窗口没有同步定位，导致候选框残留在原地。解决第一步是确认ImeMode是否被设成On——很多模板默认是NoControl，这会干扰输入法接管；第二步可以在SelectionChanged事件里调用 Invalidate 触发布局刷新；最直接的绕开方案是关闭WordWrap并保持横向滚动条一致性。
不推荐去改系统级 IME 设置，那是全局行为，会波及所有应用。正确做法是在程序里把editor.ImeMode = ImeMode.On，并在打开文件设置文本后调用一次editor.Select(editor.TextLength, 0)强制刷新文本区域，让 IME 重新计算窗口位置。这个问题属于典型的“查资料搜不到、自己试半天”的玄学——但根源通常是 IME 窗口跟随的是控件坐标而不是文本光标坐标，所以任何改变视口滚动位置的操作都可能导致轻微偏移。
4.3 现象：用代码完成批量替换后，点 Undo 没有反应，或撤销回的是一个中间态
原因：如 3.1 所述，RichTextBox 的内置撤销栈会记录每一次SelectedText赋值，而批量替换往往在一个循环里做了多次赋值，于是内置撤销可能只能退到上一次替换，而不是替换前。此时要么用editor.ClearUndo()把整个批量替换变成不可分的“一步”——代价是用户丢了之前所有手动修改的撤销历史；要么引入自定义命令栈，才是彻底解法。
实践中我的选择是：小范围替换用内置 Undo，大范围批量或全局替换走自建命令栈。很多人图省事直接把所有操作都放到底层控件上，结果就是“功能有了，撤销乱了”。如果你确定要走内置栈，更合理的姿势是在批量替换前保存一次SelectionStart，完成后统一调用editor.Select(保存的位置, 0)，这至少能避免光标跳动扰乱后续撤销定位。
4.4 现象：在 4K 屏或 150% 缩放下，工具栏图标发虚，编辑器文字边缘也有毛刺
原因：WinForm 默认不声明 PerMonitorDpiV2，而 GDI+ 绘制在老版本默认 DPI 模式下会被系统拉伸，导致图标和文字模糊。解决有三步。第一步，在 app.manifest 里声明 DPI 感知模式；第二步，给MainForm设置AutoScaleMode = Dpi并确保所有容器控件的AutoScaleMode一致；第三步，如果使用了自绘图标，资源应提供 32x32 而不是 16x16 的矢量源，运行时用DpiHelper换算缩放到实际像素。
// app.manifest 中启用 PerMonitorV2 的关键节点 <application xmlns="urn:schemas-microsoft-com:asm.v3"> <windowsSettings> <dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2</dpiAwareness> </windowsSettings> </application>有些老项目为了兼容旧系统，会关闭 DPI 感知，那在 4K 屏上必然发虚，这是选择而非 bug。
4.5 现象：从浏览器复制带格式的富文本，粘贴进编辑器时字体、颜色、大小全乱掉
原因：RichTextBox支持 RTF 粘贴，而浏览器复制的是 HTML 片段，控件在做格式转换时是不完整的。处理方法是拦截Control.KeyDown的 Ctrl+V，或重写WndProc对WM_PASTE做预处理，将剪贴板内容转成纯文本再放进去：
protected override void WndProc(ref Message m) { const int WM_PASTE = 0x0302; if (m.Msg == WM_PASTE && Clipboard.ContainsText(TextDataFormat.Html)) { // 只保留纯文本，丢弃格式 var text = Clipboard.GetText(TextDataFormat.UnicodeText); if (!string.IsNullOrEmpty(text)) { SelectedText = text; return; } } base.WndProc(ref m); }这样做牺牲了粘贴富文本的能力，但换来的是可预期的格式一致性。如果你恰好需要保留格式，那就切成 RichtTextBox 自带的粘贴，但要做好不同浏览器之间格式标签互不兼容的心里准备。对于纯文本编辑器，无脑走Clipboard.GetText(TextDataFormat.UnicodeText)永远是最稳的。
5. 把“记事本”推向生产级：编码识别、语法高亮与外部工具链
5.1 编码检测与 BOM 处理：避免打开老文件就是一个乱码灾难
文本编辑器打开文件时不识别编码，等于把“乱码”这个最劝退的问题直接甩给用户。生产级的做法是先读文件头几个字节做 BOM 探测，没有 BOM 再用启发式规则判断。WinForm 的StreamReader自带 BOM 探测，但默认构造函数的行为是“如果有 BOM 就按 BOM 解码，没有就按 UTF-8”——对 GBK 等老编码这就错了。我实现了一个小型检测器：
private Encoding DetectEncoding(FileStream stream) { // 读取前 4 字节，不影响后续 stream 读取 var bom = new byte[4]; int readCount = stream.Read(bom, 0, 4); stream.Position = 0; // 回到文件头，StreamReader 才能从头读 if (readCount >= 3 && bom[0] == 0xEF && bom[1] == 0xBB && bom[2] == 0xBF) return new UTF8Encoding(true); if (readCount >= 2 && bom[0] == 0xFF && bom[1] == 0xFE) return Encoding.Unicode; // UTF-16 LE if (readCount >= 2 && bom[0] == 0xFE && bom[1] == 0xFF) return Encoding.BigEndianUnicode; // UTF-16 BE // 无 BOM 时按默认代码页（中文环境常见 GB18030） return Encoding.GetEncoding(0); // 系统 ANSI 代码页 }这段代码有几个坑要主动说明。第一，stream.Read会推进 FileStream 的位置到第 4 字节，必须把Position归零，否则后面StreamReader会从第 4 字节开始读，文件首字符丢包。第二，Encoding.GetEncoding(0)在中文系统上获取的是 ANSI 代码页 GBK/GB2312，在英文系统上是 Windows-1252，这是“随系统走”的行为，不能保证所有机器一致。如果你想让导出结果可预测，就在设置界面里把“默认编码”开放给用户选择，编辑器不得替用户做绝对判断。
5.2 语法高亮：逐行扫描、颜色分段与性能权衡
RichTextBox 的Select+SelectionColor是 WinForm 里给文本上色的经典路径。但它有一个致命性能问题：文本体量一大，逐字符设置颜色会导致控件重绘风暴，一次高亮耗时上万毫秒。所以生产级做法要遵循三个原则：只高亮可视区域、不做整体扫描、修改后全量重绘限流。
private void HighlightSyntax(RichTextBox editor, int startLine, int endLine) { editor.SuspendLayout(); for (int line = startLine; line <= endLine; line++) { var lineStart = editor.GetFirstCharIndexFromLine(line); if (lineStart < 0) break; var lineLength = editor.Lines[line].Length; // 先恢复默认色，再做关键字覆盖 editor.Select(lineStart, lineLength); editor.SelectionColor = DefaultTextColor; // 用正则在当前行找关键字 foreach (Match m in _keywordRegex.Matches(editor.Lines[line])) { editor.Select(lineStart + m.Index, m.Length); editor.SelectionColor = KeywordColor; } } editor.Select(0, 0); editor.ResumeLayout(); }这里最大的坑是editor.Lines的索引和GetFirstCharIndexFromLine的编号在换行符处理上可能不一致——Lines数组不包含每行的换行符，而GetFirstCharIndexFromLine是按控件内部行模型计算的，遇到\r\n和\n混排时容易错位。更稳的姿势是直接用正则对全文匹配，然后通过editor.GetLineFromCharIndex(m.Index)把命中行号算出来，再做范围判断，避免手掰行的索引。
高亮性能的另一条路是降低扫描频次：在TextChanged里设置一个 300ms 的防抖定时器，用户停止输入后再真正执行高亮。输入过程中只做局部重绘，把变化区域前后若干行包成最小范围重新上色。
5.3 代码片段：用 Tab 触发的模板补全机制
编辑器的高级功能里，“代码片段补全”看着高级，实现起来却只需要一个字典和一个快捷键事件。用户在输入代码时键入for再按 Tab，编辑器把它扩展成一个完整的 for 循环模板并把光标放到循环变量位置。核心实现：
private readonly Dictionary<string, string> _snippets = new() { { "for", "for (int i = 0; i < count; i++)\n{\n \n}" }, { "if", "if (condition)\n{\n \n}" }, { "class", "class ClassName\n{\n \n}" } }; private void Editor_KeyDown(object sender, KeyEventArgs e) { if (e.KeyCode == Keys.Tab && _snippets.TryGetValue(GetCurrentWord(), out var snippet)) { var insertPos = editor.SelectionStart - GetCurrentWord().Length; editor.Select(insertPos, GetCurrentWord().Length); editor.SelectedText = snippet; // 把光标移到模板内的空位 int anchorPos = editor.Text.IndexOf('\n', insertPos) + 1; // 这里要处理模板内部缩进占位符 editor.Select(anchorPos, 0); e.SuppressKeyPress = true; } }这个机制扩展起来非常方便：把代码片段定义为带占位符的字符串，用${cursor}标明光标落点，显示时替换为空白，再用IndexOf找到占位符位置定位光标。代码片段的功能边界在于不要把它做成 IDE 级别的自动补全——那需要语法分析树的配合，WinForm 场景下做到“常用模板快速展开”已经能给日常开发省掉大量机械输入。如果想要共享片段，也可以把字典持久化为一个 JSON 文件，每次启动加载，这样用户就能自己增改模板。
6. 留给你的进阶练习：自动保存与崩溃恢复，如何把编辑器做成“后悔药”
自动保存机制是文本编辑器从“玩具”走向“生产力工具”的分水岭。实现它不复杂，核心是定时器加上文件快照，但有一个很容易被忽略的设计原则：自动保存不得干扰手动保存的语义。
我会用一个System.Windows.Forms.Timer，间隔设置为 60 秒，在执行自动保存前先判断两个条件：文档是否有脏标记、距离上次保存是否超过阈值。自动保存的内容不直接覆盖原文件，而是写入一个隐藏的.autobak文件，这样用户手动保存仍保留自己的版本历史，崩溃恢复时优先加载备份文件：
private void AutoSaveTimer_Tick(object sender, EventArgs e) { if (!_dirtyFlag) return; if (_currentFilePath == null) return; // 新文档还没另存为，不做自动保存 try { var backupPath = _currentFilePath + ".autobak"; using (var writer = new StreamWriter(backupPath, false, _detectedEncoding ?? Encoding.UTF8)) { writer.Write(editor.Text); } _lastAutoSaveTime = DateTime.Now; statusBar.Text = $"已自动备份 {_lastAutoSaveTime:HH:mm:ss}"; } catch (Exception ex) { // 自动保存失败不要弹窗打断用户，写进日志即可 WriteToLog($"自动保存失败：{ex.Message}"); } }你可能会问：为什么不直接覆盖原文件？因为覆盖原文件的自动保存会在“用户手动保存”和“自动保存”之间制造竞争，用户改到一半被自动保存把文件写坏，这样的案例在真实项目里不少。作为备份旁路，.autobak 文件在用户正常手动保存成功后才删除，此时才真正让自动保存退出舞台。崩溃恢复的触发点在程序启动时：如果发现备份文件存在且原文件不存在，就询问用户“检测到上次未保存的修改，是否从备份恢复？”这个流程在实际使用里救了我很多次。
有一点要提醒你：这个功能并不适合放进所有编辑器。如果你做的是一个临时记事本，自动保存在后台频繁写磁盘会缩短 SSD 寿命，用户也不会感激你。我自己的习惯是默认关闭、设置里可打开，默认的自动保存间隔设置为 5 分钟，而不是随手定的 60 秒。观察一段时间后你会发现，大部分崩溃发生的原因是用户长时间没保存、突然断电或进程被杀，而不是边打字边保存频率不够。
最后留一个再往前一步的方向：给自动备份做成多版本轮转。每次自动保存时生成带时间戳的文件名，并只保留最近 5 份，这样用户不仅能恢复上一份，还能向前找回更早的中间状态。这一点功能量不大，但会让你的编辑器在同类项目里显得“有隐私底线”。我当初在做一个内部系统编辑器时就是靠这个功能帮一位同事找回被误删的三小时工作内容，从那以后我所有自用工具都会默认带上一份自动备份——省去解释“你为什么不早说”这种尴尬。希望帮到你。
本文还有配套的精品资源，点击获取
