micro 是一个终端里的文本编辑器,单个 12882432 字节的 exe,双击没有窗口,敲 micro 文件名 才出现界面。它想要的位置在 nano 和 vim 之间:nano 的按键习惯,加上语法高亮、鼠标定位和多光标这些现代功能。
它解决的问题是「服务器上只有 vi」。SSH 进一台干净机器,vi 的三种模式够呛,nano 又不认鼠标、不给高亮。micro 解压就能用,不改系统里的默认编辑器,用完退出就干净。
这次跑了完整一轮:解压 0.09 秒,版本命令 170 到 301 毫秒,ConPTY 里首帧 538 毫秒,打开一份 27 行的 Python 文件后语法高亮和状态栏都正常。
一个 exe 就是一个编辑器
官方 zip 5148356 字节,解开 8 个条目,其中 7 个是文件。除主程序外还有 LICENSE / README.md / man 手册 / desktop 描述 / svg 图标,后两个是给 Linux 桌面菜单用的,Windows 上可以不管。
| 文件 | 字节 | Windows 上用不用得上 |
|---|---|---|
| micro.exe | 12882432 | 主程序,唯一必需 |
| LICENSE | 1071 | MIT,留档 |
| README.md | 22486 | 安装说明与按键表入口 |
| micro.1 | 3550 | man 手册,Windows 不看 |
| micro.desktop | 233 | Linux 菜单项,不用 |
| zip 整体 | 5148356 | 解压后 8 个条目 |
版本命令 170 毫秒
连跑三次分别是 301 毫秒 / 178 毫秒 / 170 毫秒。第一次慢在杀毒软件首次扫描这个新 exe,后两次才是它的真实开销。
# 三次耗时 301 / 178 / 170 毫秒
micro.exe -version
Version: 2.0.15
Commit hash: 6a62575b
输出只有两行,没有编译时间与依赖清单。想确认是不是官方包,比一下 zip 的 sha256 更可靠。
装之前先确认三件事
它不需要运行时,但有三个外部条件会影响体验,值得先看一眼。
| 条件 | 本次实测值 | 说明 |
|---|---|---|
| 系统 | Windows 10 22H2(19045.6466) | 官方给 win64 与 win32 两个包 |
| 终端 | conhost,132 列 34 行 | 窗口放大后它会跟着重排 |
| 权限 | 普通用户 | 写系统目录里的文件才需要管理员 |
| 授权 | MIT | 可商用,可改,可再分发 |
| zip 字节 | 5148356 | 界面与语法文件都编进 exe |
zip 只有 5148356 字节,因为界面 / 语法文件 / 配色都编译进 exe 了。它不像 vim 那样依赖一堆 .vim 脚本,也不像 VS Code 那样拖着几百兆的运行时。
打开 27 行文件用 538 毫秒
首帧是按 ConPTY 里从下令到状态栏出现文件名算的。538 毫秒里有相当一部分是 cmd 与 PTY 建立的开销,程序本身的热启动在 170 毫秒上下。
| 操作 | 耗时 | 产物 |
|---|---|---|
| 解压 | 0.09 秒 | 8 个条目 |
| -version 第 1 次 | 301 毫秒 | 两行版本信息 |
| -version 第 3 次 | 170 毫秒 | 同上 |
| ConPTY 首帧 | 538 毫秒 | demo.py 已渲染,共 27 行 |
文件越大启动越慢,但很缓
538 毫秒那份文件是 27 行、约 1.1 KB。换成几万行的日志,它会先把可视区域画出来,剩下的内容在后台逐行解析,所以首帧不会等到整个文件读完。
这一点和图形编辑器不同。图形编辑器打开大文件常常卡在语法解析,micro 的取舍是先能用,再补高亮。
状态栏那四个字段
底部一行从左到右是文件名与光标位置 / 文件类型 / 换行符 / 编码。实测打开 demo.py 时显示 demo.py (1,1) | ft:python | dos | utf-8。
| 字段 | 实测值 | 什么时候有用 |
|---|---|---|
| 文件名与行列 | demo.py (1,1) | 确认光标位置,跳转前先看这里 |
| 文件类型 | ft:python | 高亮规则按它选,认错就没颜色 |
| 换行符 | dos | CRLF 与 LF 在这里一眼看出来 |
| 编码 | utf-8 | 中文乱码先查这一格 |
换行符能直接看出问题
dos 表示文件用的是 CRLF。把这份文件丢到 Linux 上跑,shebang 那行会多一个回车,报 bad interpreter。状态栏显示 dos 时就该警惕,可以用 :set fileformat unix 转过去。
编码那一格也一样。打开一份 GBK 的中文文件,它显示的不是 utf-8,而是按猜测给出的编码,猜错时中文会变成问号,这时候用 :set encoding gbk 重开。
首次启动只写一个 2 字节文件
程序目录保持干净,用户数据在 %USERPROFILE%\.config\micro。第一次退出之后目录里多了一个文件和一个空目录。
| 路径 | 字节 | 内容 |
|---|---|---|
| bindings.json | 2 | 内容是 {},只存改过的键位 |
| buffers\ | 0 | 未保存缓冲区,崩溃恢复用 |
Type "Ctrl-E" then "help" for online help.
Type "Ctrl-E" then "init" to create a user config file.
bindings.json 里没有默认键位表,只有两个字节的 {}。这一点比很多编辑器克制:不把上千行默认配置抄到用户目录,改过的键才写进去。要完整配置,得自己在命令模式里执行 init,它才会生成 settings.json。
九个按键覆盖日常编辑
按键沿用 nano 那一套,Ctrl 加字母,不分手动模式和命令模式。鼠标点击可以定位光标,拖动选中,滚轮滚屏。
| 按键 | 动作 | 实测表现 |
|---|---|---|
| Ctrl-S | 保存 | 底部提示 Saving demo.py |
| Ctrl-Q | 退出 | 有改动时先问要不要保存 |
| Ctrl-F | 查找 | 底部出现搜索框 |
| Ctrl-E | 命令模式 | 底部出现冒号 |
| Ctrl-G | 帮助 | 打开内置文档 |
| Alt-g | 键位表 | 状态栏右侧直接写着这一条 |
命令模式能改的东西
Ctrl-E 之后敲命令,和 vim 的冒号模式手感接近,但命令名是英文单词而不是缩写。
:set tabsize 4 缩进改成 4 个空格
:set fileformat unix CRLF 转 LF
:set encoding gbk 按 GBK 重读文件
:syntax off 关掉语法高亮
:reload 放弃改动重新读盘
这些设置只对当前会话生效。想长期保存,把同样的行写进 settings.json,路径和 bindings.json 同一层。
四个容易踩的地方
双击 exe 什么都不发生
它是终端程序,双击只会在后台起一个没有终端的进程然后退出。必须从 cmd 或 PowerShell 里敲 micro.exe 文件名。
中文显示成方块
conhost 的字体没有中文字模时,中文会画成方框。换成新宋体或等宽中文字体,再执行 chcp 65001 切到 UTF-8 代码页。
保存时提示没有权限
改的是 Program Files 下面的文件,普通用户写不进去。用管理员开的终端,或者把文件拷到用户目录再改。
Ctrl-V 粘不进去
Windows 终端里 Ctrl-V 是粘贴,但 micro 默认把它绑给了垂直选择。要粘贴用右键,或者改成 Ctrl-Shift-V。
什么场景值得上
经常 SSH 到别人的机器改配置的人最合适。单个 12882432 字节的 exe,scp 上去就能用,不用装包管理器也不用编译。
开着桌面的机器上也有一类场景:临时改一份 json 或 md,不想等图形编辑器起来。538 毫秒出界面,比开 VS Code 快一个数量级。
反过来,写大型项目不合适。它没有语言服务器,跳转定义和重构都欠着,连内联报错也没有。超过两千行的代码还是图形编辑器省力。
| 项目 | 数值 |
|---|---|
| exe 字节 | 12882432 |
| zip 字节 | 5148356 |
| 热启动 | 170 毫秒 |
| 首帧 | 538 毫秒 |








