企业官网建设流程全解析

许可证检测在发布流程中的位置越来越靠前。无论你是给开源项目生成 SBOM，还是给商业客户交付软件，都要先确认依赖的许可证类型、版本和约束。License Detector 这类工具的目标，是从代码目录和依赖清单中自动找出许可证证据，并输出可读、可校验的结果。标题里的 “fastest” 和 “most accurate” 是这类工具最常强调的两个方向，但真正实践时会发现：速度快和结果准往往需要不同的策略，还必须通过基准测试来验证，而不是只看宣传数据。这篇文章会围绕 License Detector 类工具的工作原理，从检测模型、最小实现、性能优化、CI/CD 集成到常见故障排查，逐步构建一个可以落地的许可证检测方案。

1. 许可证检测工具解决的是三类问题，不只是“读文件”

许可证检测看上去是“找 LICENSE 文件然后读一下”，但进入真实项目后，你会发现许可证散落在多个位置、多种格式和多种版本里。一个工具如果只处理标准 LICENSE 文件，面对复杂仓库时会漏掉大量信息。先拆解清楚边界，后面的实现才不会走偏。

1.1 从源码文件里识别许可证

源码目录里最常见的许可证证据是LICENSE、LICENSE.md、COPYING、NOTICE这类文件。但很多项目并没有把这些文件放在根目录，而是放在子模块、vendor 目录或某个组件包下面。还有一些项目只在每个源文件头部写一段声明，例如：

/* * SPDX-License-Identifier: MIT */

这段声明本身就是结构化证据。检测工具需要同时处理两种形式：独立许可证文件和代码文件头注释。

独立许可证文件的优点是文本完整，适合做全文匹配。文件头声明的优点是位置固定、关键词明确，缺点是不同项目写法差异很大，比如有人写SPDX-License-Identifier: MIT，有人写Licensed under the Apache License, Version 2.0，还有人只写一句MIT License。检测规则必须覆盖这些变体，否则会出现大量漏判。

1.2 从依赖元数据里识别许可证

现代项目一半以上的第三方组件都来自包管理器，所以只看本地源码还不够。以 Java 项目为例，pom.xml里的<licenses>节点可能已经声明了许可证。Node 项目的package.json里也有license字段，例如：

{ "name": "example-package", "version": "1.2.3", "license": "MIT" }

Go 项目则常用go.mod加单独的LICENSE文件。如果只检测源码目录，反而会把依赖源码重复扫一遍，性能差且容易误判。好的做法是先读取锁文件或模块元数据，拿到依赖清单和声明许可证，再对声明的许可证做校验。

依赖元数据虽然方便，但不能完全信任。有些包声明了license: "MIT"，实际LICENSE文件里却是另一个许可证；有些包没有任何声明，只在README.md里提了一句“BSD licensed”。因此更稳妥的策略是：元数据结果和源码扫描结果互相印证，出现冲突时交给规则或人工处理。

1.3 从 LICENSE 文件识别许可证变体

同一个许可证在不同项目里会有大量排版差异。MIT License 的文本在不同的年份、不同的版权持有人下，除了版权行不同，其余内容基本一致。Apache License 2.0 很长，但不同项目的文本高度相似。许可证检测工具要处理的，不是“完全相等”，而是“在允许差异存在的情况下是否匹配”。

常见差异包括：

• 换行符不同：LF、CRLF、CR。
• 大小写不同：MIT License和MIT license。
• 版权所有者不同：年份、人名、公司名不一样。
• 文本前后有附加说明或免责声明。
• 许可证文本被 HTML 或 Markdown 排版拆散。

这些差异要求检测器做文本归一化，然后再匹配指纹。指纹如果设计得太严格，会把正常许可证判成 UNKNOWN；设计得太宽松，又可能把两个许可证混在一起。性能和准确率的平衡点就在这里。

2. 最快和最准需要建立在一个清晰的检测模型上

工具好不好用，不只取决于用了什么算法，还取决于检测流程是否清晰。没有检测模型，代码写到最后容易变成一堆正则堆叠，无法解释结果，也无法扩展。

2.1 检测流程：发现、提取、匹配、评分

建议把检测拆成四个阶段：

1. 发现：扫描目录，找到LICENSE、COPYING、NOTICE、README、锁文件、源码文件头。
2. 提取：把候选文件转换成纯文本，去掉与许可证无关的排版噪声。
3. 匹配：把文本和许可证规则库做比较，得到候选许可证列表。
4. 评分：根据匹配长度、关键短语、元数据共同决定最终结果和置信度。

每个阶段都要保留证据。例如某个文件被识别为Apache-2.0，证据可以是“匹配到 Apache License Version 2.0 文本的 95% 内容”，也可以是package.json里的声明字段。证据会直接影响后续人工复核的效率，也方便审计时回答问题：为什么判定为这个许可证。

2.2 SPDX License Identifier 是检测结果的通用语言

检测结果不能随便写“MIT 协议”或“Apache 2”。不同人理解不完全一致，机器解析也不稳定。推荐使用 SPDX License List 中的标识符。SPDX 是 SPDX 工作组的规范，用来统一描述软件物料清单中的许可证信息，在 SBOM 和合规审计场景中使用非常广泛。

常用标识符如下：

这里特别要注意only和or-later的区别。GPL-3.0-only表示只能使用 GPL v3 这个版本，GPL-3.0-or-later表示可以升级到 v3 之后的版本。检测器如果只输出GPL-3.0，无法表达这个差异，进入审计流程后会被要求重新确认。所以尽量使用完整的 SPDX 标识符作为输出标准。

2.3 用匹配置信度替代二值结果

许可证检测很少能保证 100% 正确。一个仓库里可能出现自定义许可证、许可证拼接、多个许可证共存等复杂情况。这时候，结果不能只给MIT或UNKNOWN，还要给置信度和证据。

置信度可以设计成 0 到 1 之间的浮点数。比如：

• 匹配到完整官方许可证文本，置信度接近 1。
• 只匹配到部分关键词，置信度为 0.6。
• 元数据里声明了 MIT，但代码目录没有许可证文件，置信度 0.5。
• 没有找到任何证据，置信度 0。

输出示例：

{ "path": "vendor/example/LICENSE", "license_id": "Apache-2.0", "confidence": 0.98, "evidence": [ "matched_template: apache-2.0_license_text", "matched_length_percent: 0.96" ], "review_required": false }

review_required可以按策略生成：置信度低于阈值，或其他来源冲突时为 true。这样检测器能自动处理大部分文件，只把少数高不确定性的结果留给人工处理。

3. 一个最小可运行的许可证检测器示例

如果要理解这类工具，最好的方式是自己写一个最小版本。下面示例使用 Python，目的是演示检测流程，不追求最高性能。生产环境如果要追求极致速度，可以考虑 Go 或 Rust 实现，但核心模型是一致的。

3.1 环境准备和目录结构

需要 Python 3.10 以上版本，不需要额外安装第三方库。建议目录结构如下：

license-detector-demo/ ├── detector/ │ ├── __init__.py │ ├── cli.py │ ├── scan.py │ └── matcher.py ├── tests/ │ └── fixtures/ │ ├── mit_project/ │ │ └── LICENSE │ └── apache_project/ │ └── LICENSE └── pyproject.toml

这个项目结构保持了最小闭环：scan.py负责遍历文件，matcher.py负责匹配许可证规则，cli.py负责命令行参数和输出。

3.2 实现文件发现和文本提取

文件发现阶段的重点不是“读取所有文件”，而是“找到最可能有许可证证据的文件”。示例代码如下：

from pathlib import Path LICENSE_FILE_NAMES = { "license", "license.md", "license.txt", "copying", "copying.md", "copying.txt", "notice", "unlicense", } TEXT_EXTENSIONS = { ".md", ".txt", ".rst", ".html", ".c", ".h", ".py", ".go", ".rs", ".js", ".ts", ".java", ".kt", } def find_candidate_files(root: Path): candidates = [] for p in root.rglob("*"): if not p.is_file(): continue name = p.name.lower() if name in LICENSE_FILE_NAMES or name.startswith("license.") or name.startswith("copying."): candidates.append(p) elif name == "readme" or name == "readme.md": candidates.append(p) elif p.suffix.lower() in TEXT_EXTENSIONS: candidates.append(p) return candidates

这里把 README 也纳入候选，是因为不少小型项目只在 README 里写许可证声明。.html文件也纳入候选，用于处理以网页形式存放的许可证文本。需要注意的是，这样会引入大量无关文件，所以后续匹配规则必须能对无关文本给出低置信度。

提取阶段的核心是判读编码。优先按 UTF-8 解码，失败时再尝试 GBK 或 Latin-1：

def extract_text(path: Path) -> str: raw = path.read_bytes() for encoding in ("utf-8-sig", "utf-8", "gbk", "latin-1"): try: return raw.decode(encoding) except UnicodeDecodeError: continue return raw.decode("utf-8", errors="ignore")

使用utf-8-sig可以自动去掉 UTF-8 BOM，防止 BOM 干扰文本前几行匹配；遇到二进制文件时，errors="ignore"会把无法解码的内容丢掉，然后交给后续匹配逻辑判断。

3.3 实现许可证匹配和结果输出

匹配阶段先做一个极简规则表，只覆盖 MIT、Apache-2.0、BSD-3-Clause 和 GPL-3.0-only 等常见许可证。完整规则应该由许可证模板生成，这里用正则说明思路：

import re SPDX_RULES = [ (re.compile(r"MIT\s+License", re.IGNORECASE), "MIT"), (re.compile(r"Apache\s+License[\s\S]{0,200}Version\s+2\.0", re.IGNORECASE), "Apache-2.0"), (re.compile(r"Redistribution and use in source and binary forms"), "BSD-3-Clause"), (re.compile(r"GNU GENERAL PUBLIC LICENSE[\s\S]{0,200}Version\s+3"), "GPL-3.0-only"), ] def match_license(text: str): best_id = "UNKNOWN" best_score = 0.0 for pattern, license_id in SPDX_RULES: search = pattern.search(text) if search: score = len(search.group(0)) / len(text) if score > best_score: best_score = score best_id = license_id return best_id, best_score

这里的得分是“匹配文本长度占文件文本长度的比例”。如果文件本身就是 MIT License 文件，比例会很高；如果只是在 README 中提了一句，比例会较低。这个方法很粗糙，但能反映置信度含义。命令行入口可以这样设计：

# detector/cli.py import argparse import json from pathlib import Path from detector.scan import find_candidate_files, extract_text from detector.matcher import match_license def main(): parser = argparse.ArgumentParser(description="Minimal License Detector") parser.add_argument("scan", help="scan command") parser.add_argument("path", help="project path") parser.add_argument("--format", default="json", choices=["json", "text"]) args = parser.parse_args() results = [] for path in find_candidate_files(Path(args.path)): text = extract_text(path) license_id, confidence = match_license(text) results.append({ "path": str(path), "license_id": license_id, "confidence": confidence, }) if args.format == "json": print(json.dumps(results, indent=2, ensure_ascii=False)) else: for r in results: print(f"{r['path']}\t{r['license_id']}\t{r['confidence']:.2f}") if __name__ == "__main__": main()

运行命令：

python -m detector.cli scan ./tests/fixtures/mit_project --format text

预期输出：

tests/fixtures/mit_project/LICENSE MIT 0.99

一个可用的检测器，至少能对自己准备的 fixture 项目输出正确结果。之后要扩展规则库，还要加入依赖元数据的读取，比如package.json的license字段或go.mod的 module 信息。

注意：最小示例能跑通不代表检测器合格。你还需要准备多个许可证的 fixture，并验证检测结果不会把无关 README 误判成 MIT。

4. 从可用到最快：性能优化的四条路径

标题里的 “fastest” 听起来很直接，但要达到“快”，需要先知道慢在哪里。很多人一上来就并行扫描，结果瓶颈其实在把每个文件多次读入内存，或者正则表达式编译了成千上万次。下面按优化顺序说明。

4.1 先定位瓶颈，再优化

性能问题不能靠猜。先用cProfile或py-spy记录一段真实扫描过程：

python -m cProfile -s cumtime detector.py scan /path/to/large/repo > profile.txt

观察输出里耗时最高的函数，通常集中在几个位置：

• rglob遍历目录时，没有排除.git、node_modules、vendor目录。
• 对每个文件重复执行正则搜索，而不是先做快速排除。
• 大文件被多次完整读取，文本归一化重复执行。
• 所有文件都进入匹配阶段，低价值文件没有提前丢弃。

优化前要建立基线数据：扫描对象有多少文件、总大小、耗时、内存峰值。后续每次改动都要重新测量，不能靠“感觉快了”。

4.2 并行扫描和缓存复用

在拥有大量文件的情况下，并行能带来明显收益。Python 可以使用ProcessPoolExecutor把文件处理任务分发到多个进程：

from concurrent.futures import ProcessPoolExecutor def analyze_file(path): text = extract_text(path) license_id, confidence = match_license(text) return {"path": str(path), "license_id": license_id, "confidence": confidence} def scan_parallel(paths, workers=4): with ProcessPoolExecutor(max_workers=workers) as executor: return list(executor.map(analyze_file, paths))

并行并不总是更快，因为进程创建和文件读写本身也有开销。如果文件比较小，反串行读取可能更快；如果文件很大，内存会成为瓶颈。更稳妥的方案是先串行读取文件内容，再把“纯文本归一化和正则匹配”送去并行处理，因为这部分是 CPU 密集型。

缓存也是常见的优化手段。对文件内容计算 SHA-256，把检测结果存到本地缓存数据库或文件中。第二次扫描同一版本代码时，直接命中缓存，可以跳过匹配阶段：

license-detector scan . --cache-dir .cache

缓存要注意 key 的粒度。建议以文件路径 + 文件大小 + 文件哈希作为缓存键，避免代码变更后命中旧结果。

4.3 索引和预编译规则

正则匹配在规则数量少时差别不大，但许可证规则库动辄上百个模板，逐个搜索会非常慢。优化方向有两个：

第一，预编译所有正则或匹配器，不要在检测循环里编译规则。示例代码里的SPDX_RULES在模块加载时就已经通过re.compile生成对象，这是最基本的要求。

第二，使用更高效的匹配结构。如果匹配的是固定字符串片段，可以用 Aho-Corasick 算法一次匹配多个关键词；如果匹配的是长文本模板，可以先用哈希指纹粗筛，再对候选做精确比对。比如对许可证官方文本构建 token 索引，扫描文件时先提取关键短语，再只对命中的许可证模板做全文比对。

下面是粗筛思路的伪代码：

KEY_PHRASES = { "MIT License": {"MIT"}, "Apache License": {"Apache-2.0"}, "GNU GENERAL PUBLIC LICENSE": {"GPL-3.0-only", "GPL-2.0-only"}, "Mozilla Public License": {"MPL-2.0"}, } def find_candidate_licenses(text): candidates = set() lowered = text.lower() for phrase, license_ids in KEY_PHRASES.items(): if phrase.lower() in lowered: candidates.update(license_ids) return candidates

先粗筛得到少量候选，再对候选做完整模板匹配，能大幅减少无效的正则搜索。

4.4 用基准测试验证优化效果

优化必须用数据说话。准备一个固定语料库，里面包含许可证文件、无许可证文件、带有许可证文件头注释的源码、二进制文件、大型 JSON 日志文件。记录优化前后的耗时、内存峰值、误报数、漏报数。

示例基准记录表：

性能优化不能以牺牲准确率为代价。每次改动后都要跑同一套 fixture 和断言，确保结果没有回退。

5. 从准确到最准确：降低误报和漏报

“fastest”可以通过工程手段达到，“most accurate”则更难。许可证文本高度相似，例如 BSD-3-Clause 和 BSD-2-Clause 的文本结构基本相同，只是第三条款不同。只依赖单一证据，很容易误判。

5.1 结合包管理器元数据互相印证

一个可靠策略是把“源码文件匹配结果”和“依赖元数据声明结果”做交叉验证。以 Node 项目为例：

对于冲突情况，不能简单覆盖。建议在检测结果里输出source字段，说明结果来自metadata、file_scan还是both。策略配置可以指定“当声明许可证与扫描结果冲突时，是否强制失败”。

5.2 对许可证变体做规范化处理

文本规范化的目标是把同一个许可证的多种表达方式映射到同一个指纹。常见操作包括：

• 统一换行符为\n。
• 转为小写。
• 去掉连续的空白字符。
• 删除版权行：Copyright (c) 2012-2024 Someone。
• 去掉 Markdown 的#、链接等排版符号。
• 删除许可证文本末尾的可选声明。

规范化后，再计算全文相似度或 N-gram 相似度。选择相似度阈值时，要参考真实项目的许可证文件分布，不能只看一两个标准模板。

下面是一个简化示例：

import re def normalize(text: str) -> str: text = text.replace("\r\n", "\n").replace("\r", "\n") text = text.lower() text = re.sub(r"copyright \(c\) .*", "", text, flags=re.IGNORECASE) text = re.sub(r"\s+", " ", text) return text.strip()

这个示例只处理了部分情况，但思路是通用的：先归一化，再比较。

5.3 用人工复核和例外列表兜底

自动检测不可能替代所有人工审计。好的工具应该把“需要人看”的结果单独列出来，而不是把所有结果混在一起。

可以设计三个状态：

• approved：置信度高且不被策略拦截。
• needs_review：置信度低、来源冲突、或命中允许列表外的许可证。
• blocked：命中了禁止列表，直接构建失败。

同时维护一个例外列表，例如：

# allow-list.yaml allow: - MIT - Apache-2.0 - BSD-3-Clause review: - GPL-3.0-only - AGPL-3.0-only block: - BUSL-1.1

例外列表应该纳入版本管理，并在每次扫描前自动加载。这样既能自动化处理大多数文件，又能保证高风险许可证不会被静默放过。

6. 集成到 CI/CD 和发布流程中

单机手动扫描只是起点。要让许可证检测真正发挥作用，必须把它放进 CI/CD 流水线，让每次代码提交都能触发结果校验。

6.1 命令行工具和 API 的设计建议

如果要把检测器提供给团队使用，命令行接口需要保持简单稳定。建议至少提供两个子命令：

verify应该返回明确退出码，方便 CI 判断。例如：

license-detector verify . --allow-list allow-list.yaml

如果检测到block中的许可证，输出错误信息并退出码为 1：

BLOCKED: vendor/old-lib/LICENSE contains GPL-3.0-only Error: 1 blocked license found

6.2 与 GitHub Actions 和 GitLab CI 集成

以 GitHub Actions 为例，可以设计一个简单的 workflow：

name: license-check on: push: branches: [ main ] pull_request: jobs: license: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v4 - name: Run license detector run: | license-detector verify . \ --allow-list allow-list.yaml \ --format json \ --output report.json - name: Upload license report uses: actions/upload-artifact@v4 with: name: license-report path: report.json

GitLab CI 也可以放在.gitlab-ci.yml中，核心逻辑是一样的：先安装检测工具，再运行verify命令，最后把报告作为 artifact 保存。这里的关键不是特定平台，而是把校验逻辑收敛到一个命令上，CI 配置只负责调用和上传结果。

6.3 检测结果如何接入策略和告警

策略校验不能只做“有就走一遍”。建议把策略和代码分支绑定：

• 在main分支上强制运行，失败则合并被拒绝。
• 在发布 tag 时生成完整 SBOM，并保存到发布资产中。
• 在夜间任务中扫描全量依赖，更新风险报告。

告警也不只限于构建失败。可以输出一条结构化日志：

{ "level": "warning", "event": "license_policy_violation", "package": "vendor/old-lib", "license_id": "GPL-3.0-only", "action": "review_required" }

这样监控系统可以直接采集和告警，团队在问题影响发布之前就能看到风险。

7. 常见问题排查：现象、原因、处理方式

实际使用许可证检测器时，会遇到各种看起来奇怪的现象。下面列出几个高频问题。

7.1 扫描后出现大量 UNKNOWN

如果你扫描一个项目目录，结果里出现大量 UNKNOWN，先不要怀疑检测器坏了，先检查输入和规则。

排查表如下：

看到 UNKNOWN 不要急着加正则，先确认“证据文件是否被正确发现”和“文本是否被正确提取”。这两个环节出错，后面的匹配再怎么优化都没用。

7.2 多个许可证版本被误判

GPL-3.0-only和GPL-3.0-or-later的差异只在文本尾部，正则如果只匹配到 “GNU GENERAL PUBLIC LICENSE Version 3” 就停止，就无法区分。类似问题也会出现在BSD-2-Clause和BSD-3-Clause之间。

推荐做法是：先用宽规则把候选许可证缩小到几个，再对候选做完整模板比对，并比较“是否包含版本后缀描述”。例如：

def refine_gpl(text: str, license_id: str) -> str: if license_id.startswith("GPL"): if re.search(r"or \(at your option\) any later version", text): return "GPL-3.0-or-later" return "GPL-3.0-only" return license_id

这个示例只处理 GPL，但思想是可迁移的：把“需要细分的规则”从第一阶段查询中拆出来，进入第二阶段精确判断，避免第一阶段快速匹配造成误判。

7.3 扫描慢、内存占用高

现象是扫描一个中等规模仓库耗时几十秒，内存一度超过 1 GB。常见原因包括：

• 没有排除node_modules、.git、dist、build目录。
• 对每个文件都执行了完整正则匹配，没有粗筛。
• 把文件内容全部读入内存后同时保留多个副本。
• 用rglob("*")遍历时没有按文件类型过滤。

排查顺序建议：

1. 用find或du看目录规模和文件数量。
2. 用cProfile看耗时函数。
3. 用memory_profiler看内存占用是否集中在提取阶段。
4. 检查是否重复读取同一文件。

解决方案是增加排除目录、启用压缩后的小文件缓存、先做粗筛再精匹配。如果扫描对象包含大量二进制文件，可以在发现阶段就用 MIME 类型过滤，不把二进制文件交给文本匹配。

7.4 许可证文件编码和特殊字符干扰

有些项目把许可证文件保存为 UTF-8 with BOM，有些是 GBK，还有 HTML 格式。检查方式：

file LICENSE

输出可能是Unicode text, UTF-8 (with BOM) text或ISO-8859 text。如果提取阶段只按 UTF-8 解码，GBK 内容会变成乱码，匹配结果自然不准。处理方式参考前面的extract_text函数，按候选编码依次尝试，并保留原始编码信息：

{ "path": "LICENSE", "encoding": "utf-8-sig", "license_id": "MIT" }

如果发现许可证文件包含 HTML 标签，需要先剥离标签再归一化。如果文件被压缩工具或加密工具处理过，检测器无法读取是正常的，应该把它列入排除列表或由人工处理。

8. 最佳实践：从能检测到能上线

一个许可证检测工具从能运行到能上线，中间还有不少工程细节。下面这组实践建议，是实际接入项目时最值得优先做的。

8.1 许可证检测上线前检查清单

上线之前，至少检查以下内容：

• 是否使用 SPDX License Identifier 作为输出标准。
• 是否同时处理源码文件和依赖元数据。
• 是否提供 JSON 结构化输出，方便后续接入其他系统。
• 是否维护 allow-list、review-list、block-list。
• 是否在 CI 中使用verify命令并检查退出码。
• 是否保存每次扫描的原始报告，方便审计追溯。
• 是否准备好包含不同许可证的 fixture 测试集。
• 是否记录基准测试数据和规则变更历史。

这些检查项可以直接落到团队的检出清单中，每次接入新仓库时逐项确认。

如果是快速体验，可以在本地用一个小型 Node 或 Go 项目试跑，重点关注：能识别多少种许可证、UNKNOWN 占比多少、扫描耗时多少、生成报告能否被阅读。

生产环境还需要额外考虑规则库更新频率。许可证模板不是静态的，SPDX 会发布新版本，新的许可证也会出现。检测工具需要支持外部规则包更新，而不是让规则硬编码在二进制中。

8.2 学习环境与生产环境的区别

学习环境里，可以直接扫描单个仓库，查看输出结果，甚至把阈值调低，观察匹配规律。生产环境则要保持谨慎：

生产环境下还建议把许可证检测结果和 SBOM 生成绑定。这样每次发布不只是得到一个许可证扫描结果，而是生成一份完整物料清单，客户和审计方都会需要。

8.3 下一步扩展方向

完成基础检测后，可以从以下几个方向继续扩展：

• 增加更多规则的自动化生成，比如从 SPDX 官方模板生成匹配器。
• 把检测结果与漏洞扫描结果联动，形成“许可证风险 + 安全风险”的综合报告。
• 支持更多包管理器，包括 Maven、npm、Go modules、Cargo、pip、NuGet。
• 加入许可证兼容性判断，比如 GPL 系列与其他许可证的组合是否允许。
• 提供 Web 界面或代码评审机器人，让开发者在提交 PR 时直接看到许可证变化。

一个许可证检测工具的价值，不在于它一次能识别多少文件，而在于它能否在发布链路中持续提供确定、可追溯、可解释的结论。即便是最小实现，只要把发现、提取、匹配、评分这个流程走通，后续扩展规则和性能优化都会清晰很多。

实际项目里最值得投入的不是写更多正则，而是建好基准语料和人工复核流程。基准语料保证每次规则调整不会破坏已有能力，人工复核流程保证自动工具处理不了的情况有明确出口。这两件事做好，License Detector 才能真正从演示工具变成发布流程里可靠的一环。