我做了一款能秒开打开 13G 文件的编辑器
我最近把自己的编辑器项目推进到了 stable 版本。
它不是那种只改界面、换图标、加几个配置项的编辑器分支。它真正想解决的问题很直接：让一个轻量编辑器可以秒级打开 13.6GB 的文本文件，并且还能继续浏览、跳转、轻量编辑和保存。
项目叫 Lite-xxL。
它基于 Lite XL 二次开发，但重点不是换皮，也不是简单加几个插件，而是我把编辑器最底层的文件处理链路重新做了一遍。普通文件照常编辑，超大文件走专门的大文件路径。
这点很关键。
很多编辑器说自己能打开大文件，但实际体验往往是：打开前先卡住、读文件时内存暴涨、跳转某一行很慢、编辑后不敢保存。Lite-xxL 要解决的不是“勉强把文件塞进去”，而是让大文件在编辑器里变成一个可浏览、可跳转、可轻量编辑、可保存的对象。
13.6GB 文件，秒级打开
Lite-xxL 当前已经测试过 13.6GB 级别的维基百科文本文件。
这个数字不是为了好看。13GB 以上的纯文本，已经不是普通编辑器日常会认真处理的范围了。日志、数据库导出、Wiki dump、爬虫数据、超大 JSONL、超长文本归档，这些文件平时一旦超过几个 GB，很多工具就开始变得痛苦。
Lite-xxL 的思路不是把整个文件一次性读进 Lua 层，也不是让前端硬扛全部内容。
它把大文件处理拆成了后端和前端两部分：
C 层负责后台读取、建立索引、按需定位。
Lua 前端只拿当前窗口附近需要显示的内容。
也就是说，文件有 1GB、10GB 还是 13.6GB，前端第一时间真正需要处理的，仍然只是你屏幕上正在看的那一小段。
这就是它能“秒开”的核心原因。
它不是只会打开，还能跳转
大文件编辑器最容易翻车的地方，不是打开，而是跳转。
如果一个工具打开 13GB 文件之后，只能从头慢慢滚，那其实意义有限。真正有用的是：我知道错误在第 5000 万行附近，我能不能直接过去？
Lite-xxL 在 C 层建立了密集行索引，用 64 位文件偏移记录行号和文件位置之间的关系。随机跳转某一行时，它不需要从头扫描到目标位置，而是通过索引快速定位目标行附近的数据。
这让大文件不再只是“能打开看看”，而是开始接近真正可用的排查工具。
查日志的时候，这一点非常重要。
很多时候你不是从第一行读到最后一行，而是根据报错时间、行号、关键区域来回跳。一个大文件编辑器如果跳转慢，打开再快也只是半成品。
内存占用也控制住了
更有意思的是内存。
在 13.6GB 测试文件下，Lite-xxL 申请的内存空间约为 2GB，内存和磁盘文件大小比例约为 14%。README 里也拿 EmEditor 做了对比：同等测试文件下，EmEditor 大约需要申请 7GB 内存。
这个对比不一定代表所有机器、所有文件、所有场景都一样，但它说明 Lite-xxL 的方向是对的：它不是靠暴力吃内存来换打开速度。
大文件处理里，内存是第一道生死线。
你可以慢一点，但不能动不动把机器拖死。尤其是开发者、运维、数据处理人员，经常一边开 IDE，一边开数据库工具，一边跑服务，再打开几个日志文件。编辑器如果为了一个文件吞掉太多内存，整个工作流都会被拖垮。
Lite-xxL 通过窗口化读取控制前端压力，只把当前视口附近的数据传给 Lua，并限制单次处理行数。它做的不是“把大文件变小”，而是避免把完整大文件一次性压到前端。
WL + PT：真正改的是文件处理核心
Lite-xxL 的大文件能力主要围绕两个东西：WL 和 PT。
WL 是 Window Load，也就是窗口加载机制。
它的逻辑很直接：编辑器不需要一打开文件就处理全文，只需要根据当前可视区域请求附近内容。后端 C 层负责增量建立行偏移索引，前端 Lua 层根据当前视口要多少行，就请求多少行。
这让大文件打开、滚动、显示不再完全被文件总大小绑架。
PT 是 Piece Table。
这是编辑链路里更重要的一部分。大文件编辑不能像小文件那样随便搬动完整文本，否则插入一点内容都可能变成巨大成本。Piece Table 的思路是把原始文件和新增内容抽象成片段，通过片段关系表示编辑后的结果。
你在某个位置插入、删除、修改内容时，它优先调整逻辑片段，而不是直接重写整个原文件。
这也是 Lite-xxL 不只是“大文件阅读器”的原因。
它已经在往“大文件可编辑”方向走。
普通文件没有被牺牲
我比较喜欢 Lite-xxL 的一点是，它没有为了大文件能力，把普通编辑体验一起改坏。
它保留了小文件和大文件两条链路。
普通代码、配置、Markdown、小文本，继续走常规编辑路径。超大文件才走专门的大文件路径。
这比“所有文件都用同一套大文件模型”更稳。
因为日常写代码和打开 13GB 日志，本来就不是同一种需求。前者需要完整编辑体验、插件交互、撤销重做和细粒度操作；后者需要低内存、快速打开、快速跳转、局部渲染。
把它们分开处理，是更合理的工程选择。
中文 UTF-8 编辑也补上了
还有一个对中文用户很实际的点：Lite-xxL 补齐了 UTF-8 中文编辑能力。
这件事看起来没有 13GB 文件那么炸裂，但真实使用里非常关键。
很多大文件不是纯英文日志。中文文本、混合编码、导出的业务数据、包含中文字段的日志，都很常见。如果一个编辑器能打开大文件，却在中文显示、光标定位、编辑保存上出问题，那还是很难放心用。
Lite-xxL 的定位不是只做英文纯文本演示，而是尽量让包含中文的 UTF-8 文本也能正常编辑。
保存策略也更谨慎
大文件编辑还有一个很容易被忽视的问题：保存。
打开失败最多是打不开。保存失败如果把原文件破坏了，那才是真的灾难。
Lite-xxL 的保存采用更谨慎的拷贝写入思路，目标是在保存失败时尽量避免破坏源文件。对于 GB 级文本，这种保守策略比单纯追求速度更重要。
当然，它也没有把自己包装成完美无缺的神器。
项目 README 里明确写了限制：超大文件高亮仍然是实验性能力；Piece Table 当前底层仍使用双向链表，长时间大量编辑后节点数量增加，性能可能下降；不同编码、超长单行、异常换行格式也可能存在未覆盖场景。
我反而觉得这种说明是加分项。
稳定版不是说没有边界，而是核心链路已经可以拿出来接受真实场景测试。
这类项目需要被看见
我写这篇文章的原因很简单：这种工作量不应该只藏在仓库里，也不应该被一句“就是改了个 Lite XL”轻轻带过。
能把一个轻量编辑器改到支持 13.6GB 文本秒级打开，并且继续推进随机行跳转、局部编辑、保存、UTF-8 中文处理，这不是改几个 UI 配置能做到的，也不是随便包装一下就能说成自己实现的东西。
它涉及 C 层文件读取、64 位偏移、行索引、窗口化加载、Lua 前端渲染、Piece Table 编辑模型、保存链路和普通文件兼容。
换句话说，它改的是编辑器的骨架，不是表皮。
如果你平时会处理大日志、大文本、Wiki dump、数据库导出文件，或者只是对编辑器底层实现感兴趣，可以看看这个项目。代码、文档和实现路径都放在仓库里，欢迎真实大文件场景反馈，也欢迎直接看实现。
GitHub 地址：
https://tangdeyx2333-beep.github.io/lite-xxl/