上周四下午，我在提交一个前端项目前，按惯例要核对改动文件的行数。之前用 IDE 自带的功能，得一个个文件点开看属性，再手动加起来，三个文件花了 12 分钟。那天我直接把代码粘进行数统计工具，页面顶部同时给出行数、词数、字符数，10 秒钟拿到结果，和 git diff 里显示的改动量对得上。省下的时间够我把测试用例再跑一遍。
最快出结果的路径是什么？
打开 hangshu.quan77.cn 后，光标默认落在文本框里，直接粘贴内容，结果实时刷新，不用点任何按钮。页面下方有「行」「词」「字符」三个统计项，字符数还细分了含空格和不含空格两种。如果你只需要行数，看第一个数字就行。
这里有个容易忽略的细节：工具统计的是「换行符」的数量，不是「可见行」的数量。如果你粘贴的内容末尾没有换行符，最后一行不会被计入。这和 unix 的 wc -l 行为一致。所以拿到数字后，先确认原文末尾是否有空行，再决定要不要加 1。
代码提交前，行数、词数、字符数分别怎么用？
第一个场景是代码审查。我在核对一个同事的重构分支时，他声称删了 200 行冗余代码。我把改动前后的两个文件分别粘进工具，前一个 847 行，后一个 641 行，差值是 206 行，和他说的基本吻合。但这里真正有用的是字符数——如果只看行数，把 10 行压缩成 1 行也能骗过统计，而字符数能反映实际的代码体积变化。那次我注意到字符数只少了 3%，说明删掉的多是空行和注释，逻辑复杂度没降，审查重点就应该放在函数结构上。
第二个场景是文档校对。我写技术方案时，需求方要求正文不超过 3000 字。我把 Markdown 源文件粘进去，看「词」这一栏——中文按空格分词，英文按空格分词，混合内容也能大致估算。当时显示 2874 词，符合要求。如果你用的是 Word，它统计的「字数」包含标点，和这个工具有差异，但作为快速估算够用了。
第三个场景是日志分析。我在排查一个接口的报错频率，从日志系统导出了一段文本，想知道有多少条独立记录。日志每行一条，行数就是记录条数。我粘进去看到 1,203 行，然后按时间过滤后再粘一次，对比两个数字就能算出占比。这个场景下，词数和字符数没什么用，但行数能直接给出量化结论。
什么时候别用它？
这个工具对纯文本和代码文件处理得很好，但有两个边界你要知道。
第一，二进制文件不行。如果你粘贴的是编译后的文件内容，或者包含大量特殊控制字符的文本，统计结果会失真。比如 PDF 或 Word 文档直接复制出来的内容，往往带有很多不可见字符，行数会偏多。这种情况应该用文件本身的属性查看，或者用专门的解析工具。
第二，编码混乱的文本会出问题。如果你的文本里混着 GBK 和 UTF-8 编码的内容，字符数统计会不准确。工具默认按 UTF-8 处理，遇到无法解析的字节序列会跳过或按替换字符计算。我试过一次从老系统导出的 GBK 编码日志，字符数比实际少了约 8%。所以跨编码场景下，先转码再统计。
另外，如果你需要统计多个文件的总行数，这个工具一次只能处理一个文本块。虽然你可以把多个文件内容拼接后粘贴，但这样会丢失文件边界。这种情况建议用命令行 wc -l *.js 直接算，效率更高。
搭配哪些工具更顺手？
行数统计适合和代码对比工具配合使用。我通常先用 diff 工具看改动，再用行数统计验证规模。如果你在做文本处理，需要先清洗数据再统计，可以搭配在线正则测试工具，把多余空格和空行去掉后再粘进来，结果更准确。
对于经常写技术文档的人，行数统计和 Markdown 编辑器是固定组合。编辑器里看不到实时字符数，写完后粘到行数统计里过一遍，确认长度达标再提交。这个流程我用了两个月，每次能省下 5 到 8 分钟的校对时间。
工具本身没有账号体系，不保存你的内容，数据只在浏览器里过一遍。如果你处理的是敏感代码，这个特性反而是优势——不用担心内容被存到服务器。但如果你需要历史记录，它给不了，得自己保存原始文本。