1. 项目概述为什么我们需要一个VC语法高亮类在Windows桌面应用开发尤其是使用MFC或Win32 API进行工具、编辑器或IDE插件开发时我们经常会遇到一个看似基础但实现起来颇为繁琐的需求为代码编辑控件如CRichEditCtrl或自定义的编辑窗口实现语法高亮。市面上成熟的IDE如Visual Studio本身提供了强大的高亮功能但当我们想为自己的小工具、脚本编辑器或者配置界面增加代码着色时却往往发现没有现成的、轻量级的解决方案可以直接拿来用。自己从头实现那意味着要和文本缓冲区、字符索引、正则表达式、属性标记、绘制消息打交道想想就头大。这就是“VC语法关键字高亮显示类”这个项目的价值所在。它不是一个庞大的库而是一个聚焦于解决特定痛点的、可复用的C类。其核心目标很明确接收一个文本输入比如一个字符串或编辑控件的内容识别出其中的VC语言关键字如int,class,for,public等、数据类型、注释和字符串字面量并以不同的颜色和样式如加粗将它们渲染出来从而极大提升代码的可读性。你可能觉得用现成的Scintilla或Syntax Edit控件不就行了确实对于新项目它们是优秀的选择。但在很多遗留项目、轻量级工具或者对控件外观、行为有高度定制化需求的场景下引入一个庞大的第三方库可能得不偿失。此时一个几百行代码、只依赖标准库和基础GDI的自实现高亮类就显得非常优雅和实用。它让你对高亮的逻辑有完全的控制权从关键字的定义、颜色的搭配到性能的优化都可以按需调整。接下来我将以一个从业者的视角拆解如何从零构建这样一个高亮类并分享在实际集成到MFC应用中时遇到的坑和技巧。无论你是想为内部工具增加一点“专业感”还是学习Windows下文本渲染的底层机制这篇文章都能给你提供一条清晰的路径。2. 核心设计思路与架构拆解实现语法高亮本质上是一个“词法分析属性标记实时渲染”的过程。我们不能简单地在用户每输入一个字符后就遍历整个文档进行正则匹配那在长文档下会卡得无法使用。因此设计必须兼顾准确性和性能。2.1 词法分析器的轻量化设计一个完整的C词法分析器需要处理宏、模板、转义字符等复杂情况。但对于高亮显示我们可以适当简化采用基于有限状态机FSM的逐行或分段扫描策略。我们的高亮类CSyntaxHighlighter的核心状态可以定义为默认状态等待识别新的语法元素。关键字/标识符状态正在识别一个可能的关键字或标识符。字符串字面量状态识别由双引号括起的字符串需要处理转义字符\。字符字面量状态识别由单引号括起的字符。单行注释状态识别以//开始的注释直到行尾。多行注释状态识别以/*开始的注释直到遇到*/。在扫描文本时我们按字符推进根据当前字符和状态决定下一个状态。例如在默认状态下遇到字母则进入“关键字/标识符状态”并开始收集字符遇到/则需查看下一个字符是/还是*以决定进入注释状态。2.2 关键字匹配的策略选择如何高效地判断一个收集到的标识符是否是关键字最直接的方法是用std::unordered_setstd::string或std::setstd::string存储所有VC关键字。unordered_set基于哈希表平均查找时间复杂度为O(1)是首选。class CSyntaxHighlighter { private: std::unordered_setstd::string m_keywords; // 初始化关键字集合 void InitKeywords() { m_keywords.insert(int); m_keywords.insert(class); m_keywords.insert(for); m_keywords.insert(while); m_keywords.insert(public); m_keywords.insert(private); // ... 添加所有C98/11/14/17常用关键字 } public: bool IsKeyword(const std::string word) const { return m_keywords.find(word) ! m_keywords.end(); } };注意C关键字列表会随标准更新而扩展。如果你的工具需要支持特定的标准如C17的co_await务必更新这个集合。一个常见的技巧是将关键字列表放在一个外部配置文件或头文件中便于维护和扩展。2.3 与编辑控件的集成方式高亮类本身不负责文本存储和用户交互它只提供“染色”功能。因此我们需要定义清晰的接口。通常有两种集成模式主动染色模式高亮类持有文本缓冲区的副本或引用。当文本改变时外部调用高亮类的Rehighlight()方法该方法返回一个描述每个字符或文本区间颜色属性的数据结构如std::vectorTextAttribute。然后由UI控件根据这个数据结构进行绘制。被动查询模式UI控件在绘制每一行文本时例如响应WM_PAINT或OnDrawItem消息将当前行的文本传递给高亮类的HighlightLine()方法该方法即时分析并返回该行的颜色属性数组控件据此进行绘制。对于MFC的CRichEditCtrl由于其内部使用RTF格式我们可以采用第一种模式生成带有颜色格式的RTF代码然后一次性设置给控件。这种方式效率高但实现稍复杂。对于自定义绘制的控件第二种模式更灵活也便于实现语法高亮的实时更新。在本项目中为了通用性我们将采用被动查询模式作为核心接口设计因为它对文本存储方式没有要求耦合度最低。3. 核心类的详细实现与关键代码解析下面我们开始构建CSyntaxHighlighter类。我将分步骤解释关键成员和方法并提供可直接使用的代码片段。3.1 定义文本属性与颜色方案首先我们需要定义如何描述一个字符或一段文本的显示属性。// SyntaxHighlighter.h #pragma once #include string #include vector #include unordered_set // 表示一个文本区间的属性起始索引长度颜色等 struct TextSpan { size_t start; // 在行内的起始索引从0开始 size_t length; // 区间长度 COLORREF color; // 文本颜色RGB值 bool bold; // 是否加粗 TextSpan(size_t s, size_t l, COLORREF c, bool b false) : start(s), length(l), color(c), bold(b) {} }; // 预定义的颜色方案 struct ColorScheme { COLORREF keywordColor RGB(0, 0, 255); // 蓝色经典关键字色 COLORREF typeColor RGB(43, 145, 175); // 青蓝色用于数据类型 COLORREF stringColor RGB(163, 21, 21); // 棕红色字符串 COLORREF charColor RGB(163, 21, 21); // 同字符串色或稍变 COLORREF commentColor RGB(0, 128, 0); // 绿色注释 COLORREF numberColor RGB(128, 0, 128); // 紫色数字 COLORREF defaultColor RGB(0, 0, 0); // 黑色默认文本 };TextSpan结构体是高亮信息的载体。ColorScheme允许用户自定义配色这是提升工具专业度和用户体验的重要一环。你可以提供几套预设方案如VS Dark、Solarized Light。3.2 高亮引擎的状态机实现这是类的核心。我们将实现一个ParseLine函数它输入一行字符串输出该行所有的TextSpan。// SyntaxHighlighter.cpp (部分核心代码) std::vectorTextSpan CSyntaxHighlighter::ParseLine(const std::string line, int lineState) { std::vectorTextSpan spans; size_t i 0; size_t lineLen line.length(); // lineState 用于传递跨行状态例如是否处于多行注释中。 // 0: 默认 -1: 在多行注释中其他状态可自定义 int state (lineState -1) ? STATE_ML_COMMENT : STATE_DEFAULT; size_t tokenStart 0; std::string token; while (i lineLen) { char ch (i lineLen) ? line[i] : \0; // 用空字符作为结束哨兵 switch (state) { case STATE_DEFAULT: if (std::isalpha(ch) || ch _) { // 开始识别标识符或关键字 state STATE_IDENTIFIER; tokenStart i; token.clear(); token.push_back(ch); } else if (ch ) { state STATE_STRING; tokenStart i; } else if (ch \) { state STATE_CHAR; tokenStart i; } else if (ch / (i1) lineLen) { char nextCh line[i1]; if (nextCh /) { // 单行注释从当前位置到行尾都是一个颜色区间 spans.emplace_back(i, lineLen - i, m_scheme.commentColor); i lineLen; // 跳到行尾结束本轮解析 continue; } else if (nextCh *) { state STATE_ML_COMMENT; tokenStart i; i; // 跳过* } } else if (std::isdigit(ch)) { // 简单数字识别实际项目需要更复杂的正则处理浮点数、十六进制等 state STATE_NUMBER; tokenStart i; } // 其他字符运算符、括号等保持默认颜色无需特殊处理 break; case STATE_IDENTIFIER: if (std::isalnum(ch) || ch _) { token.push_back(ch); } else { // 标识符结束判断是否为关键字 if (IsKeyword(token)) { spans.emplace_back(tokenStart, token.length(), m_scheme.keywordColor, true); // 关键字加粗 } else if (IsDataType(token)) { // 假设有一个判断数据类型的函数 spans.emplace_back(tokenStart, token.length(), m_scheme.typeColor); } // 重置状态并回退一个字符重新处理当前字符 state STATE_DEFAULT; i--; // 重要回退以便在默认状态下处理当前字符可能是运算符等 } break; case STATE_STRING: if (ch ) { // 字符串结束但需要检查前一个字符是否是转义符\ if (i 0 line[i-1] \\) { // 是转义引号字符串继续 } else { // 真正的字符串结束 spans.emplace_back(tokenStart, i - tokenStart 1, m_scheme.stringColor); state STATE_DEFAULT; } } else if (ch \0) { // 行尾了字符串还没结束说明是跨行字符串。记录状态。 spans.emplace_back(tokenStart, i - tokenStart, m_scheme.stringColor); // 设置状态通知下一行继续字符串状态 // 这里需要修改返回值不仅返回spans还要返回新的行状态。 // 为简化我们先结束当前区间。 state STATE_DEFAULT; } break; case STATE_ML_COMMENT: if (ch * (i1) lineLen line[i1] /) { // 多行注释结束 spans.emplace_back(tokenStart, i - tokenStart 2, m_scheme.commentColor); state STATE_DEFAULT; i; // 跳过/ } else if (ch \0) { // 行尾注释未结束 spans.emplace_back(tokenStart, i - tokenStart, m_scheme.commentColor); // 状态保持为STATE_ML_COMMENT并传递给下一行 } break; // ... 其他状态STATE_CHAR, STATE_NUMBER类似实现 } i; } // 处理行尾可能未结束的状态如标识符 if (state STATE_IDENTIFIER) { if (IsKeyword(token)) { spans.emplace_back(tokenStart, token.length(), m_scheme.keywordColor, true); } } // 返回结果和新的行状态用于下一行 // 实际实现中ParseLine应返回一个包含spans和newLineState的结构体 return spans; }这段代码是一个高度简化的状态机框架。在实际项目中你需要处理更多边界情况比如转义字符在字符串和字符状态中\\、\、\n等都需要特殊处理它们不应该终止字符串。数字字面量需要支持十进制、十六进制0x、浮点数.、科学计数法e。预处理指令#include,#define等通常用不同于关键字的颜色如灰色显示。跨行元素字符串和注释都可能跨越多行。我们的ParseLine函数需要接收一个“行状态”输入并返回一个新的“行状态”输出以便下一行能继续正确的解析。这是实现稳健高亮的关键。实操心得状态机的switch-case代码容易变得冗长。一个保持代码清晰的方法是将每个状态的处理逻辑封装成独立的成员函数如ProcessDefaultState(),ProcessIdentifierState()等。这样主循环会更简洁也便于单元测试。3.3 性能优化关键点语法高亮必须在用户输入时快速响应否则体验会非常糟糕。以下是几个关键的优化方向增量高亮这是最重要的优化。不要因为用户在第1000行输入了一个字符就重新高亮全部1000行。我们需要一个机制来跟踪哪些行是“脏的”内容改变了并只重新高亮这些行及其可能影响的行例如如果一行中/*被删除可能影响后面很多行的注释状态。对于简单的编辑器可以只高亮当前可见行及前后几行视口区域。关键字查找优化使用unordered_set已经是O(1)。但还可以更进一步例如对于C关键字都是小写可以在将标识符加入集合和查询前先将其转换为小写。文本分割与缓存将整个文档按行分割存储。高亮结果每行的TextSpan数组可以缓存起来。只有当某行的文本或其“行状态”发生变化时才重新计算该行的高亮。这需要维护一个“行状态”数组记录每行解析结束时的状态如是否在注释中、字符串中。避免频繁内存分配在ParseLine函数内部可以复用std::vectorTextSpan和std::string token对象而不是每次调用都新建减少动态内存分配的开销。4. 在MFC应用中集成与渲染有了高亮引擎下一步就是让它把颜色画出来。我们以集成到MFC的CEdit或CRichEditCtrl为例。CEdit是纯文本控件不支持部分文本着色所以我们需要用自定义绘制或者改用CRichEditCtrl。4.1 方案一使用CRichEditCtrl与RTF流CRichEditCtrl支持RTF格式我们可以将高亮后的文本转换成RTF代码然后设置给控件。// 将一行文本及其高亮信息转换为RTF片段 CString ConvertToRtfFragment(const CString lineText, const std::vectorTextSpan spans) { CString rtf _T(); size_t lastPos 0; for (const auto span : spans) { // 添加span之前的普通文本 if (span.start lastPos) { rtf EncodeRtfText(lineText.Mid(lastPos, span.start - lastPos)); } // 添加高亮文本 rtf.AppendFormat(_T(\\cf%d\\b%d ), GetRtfColorIndex(span.color), span.bold ? 1 : 0); rtf EncodeRtfText(lineText.Mid(span.start, span.length)); rtf _T(\\cf0\\b0 ); // 重置颜色和加粗 lastPos span.start span.length; } // 添加剩余文本 if (lastPos lineText.GetLength()) { rtf EncodeRtfText(lineText.Mid(lastPos)); } rtf _T(\\par\r\n); // RTF段落结束 return rtf; } // 更新整个控件内容全量更新性能较差仅作示例 void CMyRichEditCtrl::UpdateHighlight() { CString fullRtf _T({\\rtf1\\ansi\\deff0{\\fonttbl{\\f0 Courier New;}}\\viewkind4\\uc1\\pard\\f0\\fs20); for (int i 0; i GetLineCount(); i) { CString lineText GetLineText(i); // 需要实现GetLineText函数 auto spans m_highlighter.ParseLine(CT2A(lineText), GetLineState(i)); fullRtf ConvertToRtfFragment(lineText, spans); } fullRtf _T(}); SetWindowText(fullRtf); // 注意这会替换整个RTF内容丢失光标位置等 }注意直接SetWindowText会重置控件的所有状态光标、选择、滚动条位置。正确的做法是使用StreamIn和StreamOut函数与EDITSTREAM结构配合进行更精细的文本替换。全量更新RTF在文档较大时性能瓶颈明显仅适用于小文档或演示。4.2 方案二自定义绘制Owner Draw如果你使用CEdit或者自绘控件可以在WM_PAINT或WM_DRAWITEM消息中自己绘制文本。这给了你最大的灵活性但实现也更复杂。子类化控件从CEdit派生一个新类例如CSyntaxEdit。处理WM_PAINT在OnPaint函数中先调用默认绘制擦除背景然后获取设备上下文DC。计算可见行根据控件的字体高度和滚动位置计算出当前可见区域对应的行号范围。逐行绘制对于每一可见行调用m_highlighter.ParseLine获取高亮区间然后使用CDC::TextOut或CDC::DrawText根据TextSpan的颜色和属性分段绘制文本。处理光标和选择你需要自己计算光标位置行、列并在绘制时高亮选中的文本区域。这涉及到从像素坐标到字符索引的转换非常繁琐。void CSyntaxEdit::OnPaint() { CPaintDC dc(this); CRect rect; GetClientRect(rect); // 1. 设置背景色和字体 dc.FillSolidRect(rect, RGB(255, 255, 255)); // 白色背景 CFont* pOldFont dc.SelectObject(m_font); // m_font为等宽字体如Courier New // 2. 计算文本度量 TEXTMETRIC tm; dc.GetTextMetrics(tm); int lineHeight tm.tmHeight tm.tmExternalLeading; int charWidth tm.tmAveCharWidth; // 等宽字体假设 // 3. 获取滚动偏移和可见行 CPoint scrollPos GetScrollPosition(); int firstVisibleLine scrollPos.y / lineHeight; int lastVisibleLine firstVisibleLine (rect.Height() / lineHeight) 1; // 4. 逐行绘制 for (int lineIdx firstVisibleLine; lineIdx lastVisibleLine lineIdx GetLineCount(); lineIdx) { CString lineText GetLineText(lineIdx); auto spans m_highlighter.ParseLine(CT2A(lineText), GetLineState(lineIdx)); int xPos -scrollPos.x; // 水平滚动偏移 int yPos lineIdx * lineHeight - scrollPos.y; size_t lastCharPos 0; for (const auto span : spans) { // 绘制span之前的普通文本 if (span.start lastCharPos) { CString normalText lineText.Mid(lastCharPos, span.start - lastCharPos); dc.SetTextColor(m_scheme.defaultColor); dc.TextOut(xPos, yPos, normalText); xPos normalText.GetLength() * charWidth; } // 绘制高亮文本 CString highlightText lineText.Mid(span.start, span.length); dc.SetTextColor(span.color); if (span.bold) { CFont boldFont; LOGFONT lf; m_font.GetLogFont(lf); lf.lfWeight FW_BOLD; boldFont.CreateFontIndirect(lf); dc.SelectObject(boldFont); dc.TextOut(xPos, yPos, highlightText); dc.SelectObject(m_font); // 恢复原字体 boldFont.DeleteObject(); } else { dc.TextOut(xPos, yPos, highlightText); } xPos highlightText.GetLength() * charWidth; lastCharPos span.start span.length; } // 绘制行尾剩余文本 if (lastCharPos lineText.GetLength()) { CString remainingText lineText.Mid(lastCharPos); dc.SetTextColor(m_scheme.defaultColor); dc.TextOut(xPos, yPos, remainingText); } } dc.SelectObject(pOldFont); }自定义绘制的优势是性能可控特别是结合增量高亮和可见区域计算后可以做到非常流畅。缺点是需要处理所有文本编辑的副作用如光标闪烁、文本选择、复制粘贴、输入法支持等这几乎相当于重写一个简易的文本编辑器工作量巨大。4.3 方案三使用现有语法高亮控件推荐用于生产对于大多数实际项目除非有极其特殊的定制需求否则我强烈建议使用成熟的第三方控件如Scintilla这是一个开源的语法高亮编辑组件功能极其强大被Notepad、Geany等众多编辑器使用。它提供了完整的C封装ScintillaEdit可以很方便地集成到MFC或Win32项目中。它内置了C的词法分析器性能优异且支持代码折叠、自动补全、错误指示等高级功能。Syntax Edit Control一些商业MFC控件库如BCGSoft, Codejock也提供了语法高亮编辑控件通常集成度更高与MFC框架结合更紧密。使用这些控件你只需要几行代码设置语言类型和颜色样式就能获得专业级的语法高亮效果省去了大量底层开发和调试工作。5. 常见问题、调试技巧与性能调优在实现和集成过程中你肯定会遇到各种问题。这里记录一些典型的坑和解决方法。5.1 高亮错乱与状态同步问题描述在编辑代码时特别是插入或删除/*、*/、引号时后面所有行的高亮颜色都乱了。根本原因行状态lineState没有正确维护和传递。当某行的文本被修改其结束状态可能改变从而影响后续所有行。如果只重新高亮当前行后续行仍使用旧的状态缓存就会出错。解决方案实现脏行标记与传播当一行被修改将其标记为“脏”。重新高亮该行时计算其新的结束状态。如果新状态与之前缓存的状态不同则将其下一行也标记为“脏”并递归此过程直到某行的结束状态不再改变或到达文档末尾。使用行状态快照为整个文档维护一个std::vectorint存储每一行解析结束后的状态。在解析任何一行时其起始状态就是上一行的结束状态存储在快照中。修改文本后从修改行开始逐行重新解析并更新快照直到连续两行的状态与快照中一致为止。void CSyntaxDocument::OnTextChanged(int changedLine) { // 1. 重新高亮脏行 int currentLine changedLine; int oldState (currentLine 0) ? STATE_DEFAULT : m_lineStates[currentLine - 1]; while (currentLine GetLineCount()) { auto result m_highlighter.ParseLine(GetLine(currentLine), oldState); // 存储该行的高亮结果spans m_highlightCache[currentLine] result; // 检查状态是否改变 int newState result.finalState; // ParseLine需要返回结束状态 if (newState m_lineStates[currentLine] currentLine changedLine) { // 状态与之前缓存的一致且不是被修改的那一行可以停止传播 break; } // 更新状态快照 m_lineStates[currentLine] newState; oldState newState; currentLine; } // 2. 通知视图更新显示只更新从changedLine到currentLine-1的区域 InvalidateLines(changedLine, currentLine - 1); }5.2 性能瓶颈分析与优化问题描述打开一个几千行的文件或者快速滚动时界面卡顿。排查与优化使用性能分析工具使用Visual Studio的性能探查器Performance Profiler查看CPU采样报告。你会发现时间主要消耗在ParseLine函数和文本绘制上。优化ParseLine避免字符串拷贝ParseLine参数使用const std::string内部使用std::string_view来引用子串避免创建临时字符串。简化状态判断使用查找表Look-up Table来快速判断字符类别。例如一个256大小的char类型数组预先标记好哪些字符是字母、数字、运算符等。热点关键字优化统计发现int,for,if等关键字出现频率最高。可以在IsKeyword函数中先根据单词长度和首字母进行快速筛选再进行哈希查找。优化绘制只绘制可见区域这是最重要的优化。在OnPaint中精确计算需要绘制的行范围一行都不要多画。双缓冲在内存DC中先绘制完整内容再一次性BitBlt到屏幕避免闪烁。缓存文本尺寸对于等宽字体字符宽度是固定的可以提前计算好避免在绘制循环中频繁调用GetTextExtent。缓存高亮结果这是前提。不要每次绘制都重新解析。5.3 与编辑操作输入、删除、粘贴的协同问题描述高亮类工作正常但用户输入时新输入的字符没有立即高亮或者删除字符后高亮残留。解决方案你需要正确处理编辑控件的通知消息。对于CRichEditCtrl响应EN_CHANGE消息在OnEnChange处理函数中触发增量高亮逻辑。对于自定义绘制的CEdit除了EN_CHANGE可能还需要处理WM_KEYDOWN,WM_CHAR,WM_PASTE等在修改文本后立即更新受影响行的高亮缓存并触发局部重绘。一个常见的陷阱是粘贴大段文本时会触发多次EN_CHANGE。为了性能可以设置一个短暂的定时器如100ms在最后一次改变后统一进行高亮更新这称为“防抖”Debouncing。5.4 扩展性设计支持其他语言一个好的高亮类不应该只支持VC。我们可以通过抽象出“词法分析器”接口来支持多种语言。class ILexer { public: virtual ~ILexer() default; virtual std::vectorTextSpan ParseLine(const std::string line, int inOutState) 0; virtual const ColorScheme GetColorScheme() const 0; }; class CppLexer : public ILexer { /* ... 实现之前的逻辑 ... */ }; class PythonLexer : public ILexer { /* ... 实现Python语法逻辑 ... */ }; class JSLexer : public ILexer { /* ... 实现JavaScript语法逻辑 ... */ }; class CSyntaxHighlighter { private: std::unique_ptrILexer m_lexer; public: void SetLanguage(Language lang) { switch(lang) { case Language::CPP: m_lexer std::make_uniqueCppLexer(); break; case Language::Python: m_lexer std::make_uniquePythonLexer(); break; // ... } InvalidateAllHighlight(); } std::vectorTextSpan ParseLine(const std::string line, int inOutState) { return m_lexer-ParseLine(line, inOutState); } };这样高亮核心就与具体语言解耦了。添加对新语言的支持只需要实现一个新的ILexer派生类即可。6. 总结与项目价值再思考走完从设计到实现的整个流程你会发现一个健壮、高效的语法高亮类其复杂度远超最初的想象。它涉及编译器前端知识词法分析、数据结构状态机、缓存、操作系统GUI编程消息循环、GDI绘制以及软件工程模块化、性能优化。这个项目的价值绝不仅仅是“让代码变彩色”。它是一次深刻的底层技术实践深入理解文本处理你亲手实现了如何将无结构的字符流分解成有意义的语法单元Token。掌握状态机设计这是处理任何流式数据网络协议、文件解析的通用核心思想。优化性能的实战面对实时交互场景你学会了如何通过缓存、增量更新、脏标记、防抖等策略在有限资源下提供流畅体验。GUI集成经验你了解了如何将后台计算逻辑与前端显示无缝衔接处理各种边界情况和用户交互。对于个人开发者这是一个极佳的练手项目能全面提升你的C和系统编程能力。对于团队一个自研的轻量级高亮组件可以在不引入外部依赖的情况下为各种内部工具日志查看器、配置文件编辑器、小型IDE增添关键的用户体验是技术债的预防而非积累。最后如果你决定在生产环境中使用我的建议是优先评估成熟的第三方控件如Scintilla。如果它们满足需求就直接使用。只有当你有非常特殊的定制需求比如高亮一种内部DSL语言或者对二进制大小、许可协议有极端要求时才值得投入精力去打造和维护自己的轮子。但无论如何经历过自己造轮子的过程你会对“语法高亮”这个看似简单的功能抱有全新的敬意和理解。