Ctrl+G是Notepad++唯一稳定、无需配置的行定位方式;输完数字必须按Enter确认,否则无效;行号越界自动跳至末行,空文件输1或999999均停在首行开头。

Ctrl+G 是唯一稳定、无需配置、不依赖插件的行定位入口,其他所有“快捷方式”最终都走这条路——别浪费时间找替代方案。
为什么 Ctrl+G 输完没反应?
不是功能失效,是操作没提交:
- 输完数字后必须按
Enter,点对话框上的 Go 按钮无效(UI 缺陷) - 按
Esc会取消整个操作,看起来像“没反应”,其实是你退出了 - 状态栏若被关闭(右键 → 勾选 Line number),双击
Ln 42预填功能就不可用 - 光标焦点不在编辑区时(比如停在搜索框或侧边栏),
Ctrl+G仍会弹窗,但输入可能被拦截
Ctrl+G 输入行号的边界行为
Notepad++ 对行号不做校验,只做字节偏移映射,所以:
- 行号从
1开始,输0或负数会被忽略,光标停在第1行 - 文件共
87行却输999,不会报错,而是静默落到第87行末尾 - 空文件里输
1,光标停在唯一一行开头;输999999,也停在这一行末尾 - 支持
123:45格式跳转到第123行第45列(列号从0起算),但混用\r\n和\n会导致列偏移失准
命令行启动时用 -n 参数跳转的硬约束
脚本或 IDE 集成时必须严格遵循格式,否则参数被完全忽略:
- 语法是
notepad++.exe -n127 "path\to\file.txt"——-n和数字之间不能有空格 - 路径含空格必须用英文双引号包裹整个路径,如
"D:\My Project\log.txt" -
-n只对命令行中第一个文件生效,npp.exe a.txt -n10 b.txt中b.txt不会跳转 - 文件不存在时,Notepad++ 会新建空文档并把光标放到指定行——这是设计行为,不是 bug
真正容易被忽略的是:行号跳转不看内容,只认字节流。一旦文件被外部程序追加、或用不同编码/换行符重写过,之前记下的“第 123 行”就可能指向空白或乱码位置。每次跳转前,扫一眼右下角状态栏的编码(如 UTF-8)和换行符(如 Windows (CR LF))标识,比反复试 Ctrl+G 更省时间。


















