把 130 种语言的切词标注依存一次跑完（HanLP）

中文写出来没有空格做词边界，同一个字串换个上下文就是不同的词。做搜索召回、做简历解析、做内容审核的人，都得先过切分和标注这一关。HanLP 从 2014 年开始做这件事，仓库挂在 hankcs 账号下，目前 36504 star、10889 fork，主要语言是 Python，采用 Apache License 2.0。到 2.1 版本，它把分词、词性标注、命名实体识别、句法依存这些任务合并进同一套预训练模型，官方标称 10 项联合任务覆盖 130 种语言。

HanLP 是用 Python 写的多语言自然语言处理库，输入一批文本，输出分词、词性标注、命名实体、依存句法等结构化结果，面向需要中文或多语种文本处理的开发者。

它同时提供两条使用路径。本地路径装完 pip install hanlp 就能用，模型拉到本地跑，GPU 或 TPU 加速是推荐项但不是必选项。在线路径走 RESTful 接口，只发请求不装模型，官方给了 Python 的 hanlp_restful 和 Java 的 hanlp-restful 客户端，免费 auth key 需要到论坛申请，授权协议是 CC BY-NC-SA 4.0，商用场景要另看条款。

这几个项目分别在解决什么

HanLP 的重心是把多种 NLP 任务塞进一个多任务模型里一次跑完。README 列出的 10 项联合任务包括分词、词形还原、词性标注、词特征抽取、依存句法分析、成分句法分析、语义角色标注、语义依存分析和抽象语义表示（AMR）解析。输入是一批字符串，输出是每个 token 对应的多层标注。中文、英文、日文各有单语模型，官方说明这些单语模型的效果明显优于多语言模型。

模型库在持续扩充。2025 年 1 月发布的 v2.1.1 放出了一个开源古汉语模型，常量名是 hanlp.pretrained.mtl.KYOTO_EVAHAN_TOK_LEM_POS_UDEP_LZH，支持古汉语自动分词、词形还原和词性标注。2024 年 12 月的 v2.1.0 放出带 ModernBERT 编码器的英文多任务模型 EN_TOK_LEM_POS_NER_SRL_UDEP_SDP_CON_MODERNBERT_BASE。仓库还提供训练脚本，README 声称用固定随机种子可以把分词器训到 96.73 分，并承诺论文里的每一个数字都可复现，复现问题按最高优先级处理。

explosion/spaCy 走的是工业流水线路线，仓库自述为「Industrial-strength Natural Language Processing (NLP) in Python」，33949 star，是 Python 生态里做句法、实体、规则匹配最常被拿来当基础设施的一个。JohnSnowLabs/spark-nlp 把 NLP 放到 Spark 上做，4158 star，适合数据量大、已经有 Spark 集群的团队。spacy-llm 是 spaCy 的扩展，把大模型接进结构化 NLP 流水线，1395 star。

剩下几个体量小很多，方向也更窄。talmago/fast_gliner 是 GLiNER 模型的 Rust 推理绑定，14 star；The-FinAI/PIXIU 面向金融场景，893 star；prakash-ukhalkar/NLP 是一套从入门讲起的 Jupyter notebook，7 star。这三个更适合作为特定场景的补充，不适合拿来当通用文本处理底座。

逐项对照

表里的上手成本只按各仓库自身描述和可观察到的安装方式来填，不涉及实际跑测。spaCy 与 HanLP 的差别不在装得上装不上，而在装了之后默认给你什么：spaCy 给一套可组装的流水线组件，HanLP 给一个已经把十项任务焊在一起的多任务模型。

差距出现在哪

真正拉开距离的是版本线。HanLP 的 issue 模板反复要求填写版本号，用户提交的问题里出现过 1.2.4、1.8.6、2.1、3.3.1 等跨度极大的版本，社区回复常常要先纠正「你用的是哪一代」。1.x 以规则和 CRF 为主，2.x 建在 PyTorch 与 TensorFlow 2.x 之上，两套 API 和模型互不通用。spaCy 这类只维护一条主版本线的项目，用户踩错版本的几率低得多。选 HanLP 之前必须先确认自己要看的是 2.x 文档还是 1.x 文档，这一点没有捷径。

模型分发是第二处摩擦。2.1 的预训练模型体积不小，要从 file.hankcs.com 下载，issue 里就有用户卡在 Failed to load https://file.hankcs.com/hanlp/mtl/close_tok_pos_ner_srl_dep_sdp_con_electra_small_20210111_124159.zip 这条报错上。网络受限或内网环境下，这一步比装一个纯本地的轻量库麻烦得多。

真实用户踩过的坑还包括几类。繁体转换结果不符合预期，比如「舞台」被转成「舞颱」、「因为」转成「囙爲」，这条讨论有 35 条评论，当前状态是已解决。Python 2.7 环境下通过 jpype 调用出现乱码，38 条评论，已解决。CRF 分词后调用 coreStopWordDictionary.apply 结果全部为空，30 条评论，已解决。用 Spark 时单机跑正常、map 到节点上就报错，20 条评论，也已解决。这些问题都指向同一件事：跨运行时、跨版本使用时，HanLP 的行为会变。

仓库开放 issue 只有 14 个，最近一次提交是 2026-09-15，维护节奏没有停。短板也在这里：仓库归属个人账号，issue 里的提问直接称「作者」「楼主」，扩展生态不像 spaCy 那样有 spacy-llm、fast_gliner 这类第三方组件往外长。

什么情况下选它

需要中文或多语种的一次性联合标注，选 HanLP。一句 HanLP(['文本']) 就能同时拿到分词、词性、实体、依存结果，不用自己拼接多个模型，省掉的组装工作量是它最实在的价值。

要做古汉语或小语种文本处理，选 HanLP。130 种语言的覆盖加上 2025 年新增的古汉语模型，在这个区间里可替代的开源选项不多。

要复现论文分数或训练自己的模型，选 HanLP。仓库给出了固定的随机种子和完整的训练脚本，并明确承诺分数可复现。

不想碰模型下载、不想在本地装深度学习框架，或者团队完全没有中文 NLP 需求，这类场景不该选 HanLP。只想把大模型接到已有流水线上做结构化抽取，spacy-llm 更贴近需求；数据已经在 Spark 集群里，spark-nlp 少一层适配成本；只做零样本实体识别且在意推理性能，fast_gliner 更对口。用 RESTful 接口还要留意，免费 auth key 挂在 CC BY-NC-SA 4.0 之下，商用前先确认授权范围。

仓库地址在 https://github.com/hankcs/HanLP，官网文档在 https://hanlp.hankcs.com/en/，许可证为 Apache License 2.0，主要语言是 Python，代码中另有约 19% 的 Jupyter Notebook 与 1.4% 的 Java。

焚评：这个项目的量化评分

本项目的选题来自 焚.com（一个按公开公式给 GitHub 项目打分的站）。焚评当前总分 9.1 分（满分 10）。下表是各维度的得分：

评分口径、权重与计算方式见焚.com 的评分方法页；数据随 GitHub 指标刷新，具体数值以焚.com 当前页面为准。本文正文为诀.com 独立撰写，评分数据由焚.com 授权引用。