LRG 位点参考基因组 — 一千三百条永久编号，与一次停止

临床基因检测报告上常见一行字：NM_000546.6:c.743G>A。这行字看起来像身份证号，实际是一份带版本的地址。NM_ 后面的版本号会随参考序列修订而进位，c. 后面的位置也会随转录本模型调整而移动。结果是：三年前签发的一份报告，今天拿同一套工具去复算，可能算不出同一个结果，甚至定位到另一个碱基上。

Locus Reference Genomic（LRG）就是为解决这件事而生的。它由 EMBL-EBI 与 NCBI 联合建设，在诊断界、研究界与位点特异性数据库策展人的推动下，为每个有临床意义的基因位点签发一条记录，编号形如 LRG_321，不带版本号，固定段永不改动，另附一张通往 RefSeq 与 Ensembl 的对照表。报告里写 LRG_321t1:c.743G>A，十年后仍然指向同一段序列。这是「标识符稳定性」在临床遗传学里最彻底的一次尝试。

但它停在了 2021 年 3 月 31 日。官方站点每页顶部都写着：新的 LRG 不再生成，建议改用 MANE。一个把稳定性做到极致的系统，最终被一个覆盖面更广、更新更快的方案接替。这段历史本身就是选型时最该先知道的事。一屏速览见下表。

维度	内容
全称	Locus Reference Genomic（位点参考基因组）
维护方	EMBL-EBI 与 NCBI 联合，站点由 EMBL-EBI 托管
记录规模	1,325 条公开记录，一记录一基因
编号范围	LRG_1 至 LRG_1431，中间有 106 个空号未出现在公开清单中
最近发布	第 810 版，2021 年 3 月 31 日
新增状态	已停止；官网最后更新日期同为 2021 年 3 月 31 日
官方推荐替代	有 MANE Select 转录本时优先用 MANE（官网逐页横幅）
固定段内容	基因组序列、最少转录本与蛋白、LRG 专属外显子编号
可更新段内容	装配体映射、区域内全部转录本注释、旧编号对照
刷新频率	可更新段每周由脚本自动刷新
编号是否带版本	不带，这是与 NM_ / NG_ 系的根本差别
文件格式	每条记录一份 XML，另有 TSV 清单与 FASTA 序列
下载入口	EBI FTP 的 lrgex 目录，含 data_files、fasta 与若干状态子目录
许可	EMBL-EBI Terms of Use，序列可自由下载与再分发
数据性质	参考序列与注释，不含任何患者或样本数据
典型用途	临床变异报告的稳定坐标、历史报告复核、跨联盟编号换算

§1 它要解决的具体麻烦

1.1 报告里的编号会变质，而病历要保存三十年

临床遗传学的报告不是一次性的。一份肿瘤胚系检测报告可能决定患者终身随访方案，一份产前诊断报告会被写进下一代的病历，一份携带者筛查结果可能在十年后影响婚育决策。制度上，病历的保存期以十年、三十年计，某些司法辖区要求更久。也就是说，报告在签发那一刻起就被要求「未来仍然可读」。

偏偏报告上最核心的那串字符是所有东西里最容易变质的一项。NM_000546.6 里的 NM 表示 RefSeq 的 mRNA 序列，.6 是版本号。序列的注释每修订一次，版本号就进位一次：修正一个错碱基、调整一个外显子边界、发现上游另有起始密码子，都会导致版本变化。版本一变，c. 坐标的基准就变了，c.743 对应的碱基可能平移，极端情况下还会指向另一个氨基酸。

这个问题在文献里被反复记录。LRG 项目的创建背景在 2010 年《Genome Medicine》那篇方法学文章里写得很直白：随着基因结构复杂度的认识加深、基因表达细节的理解推进，准确描述致病变异变得越来越困难，部分原因正是当时的参考 DNA 序列格式不能完全满足需求。2014 年《Nucleic Acids Research》的介绍文章补充了另一半：长期存在同一基因位点使用多条序列、版本混乱的情况，导致变异报告前后不一致。官方 FAQ 里还有一句更尖锐的说明——出版物里经常不写序列版本号，一旦当前版本号大于 1，访问者就无法确定作者当初指的是哪一版。

于是 LRG 的解法是釜底抽薪：干脆不要版本号。一条 LRG 记录对应一段固定序列，该序列一经发布就不再改动。没有 .5 和 .6 之分，只有一个 LRG_321t1。要改怎么办？不改。若原记录确有错误，另建一条编号不同的新记录，旧记录继续有效。这套设计把「可变」从记录里彻底移了出去。

1.2 三条常见的错误期待

第一次接触 LRG 的人，最容易带着三种预设进来，三种都会导致后续判断跑偏。

第一种：以为它是 RefSeq 的一个分支或镜像。 这个印象来自双方确实有血缘——LRG 的基因组序列直接取该位点的 RefSeqGene 序列，记录的 XML 里也大量引用 NG_ 与 NM_ 编号。但 LRG 与 RefSeq 是两套并行的编号体系，维护逻辑完全不同：RefSeq 按 INSDC 的惯例给每条序列配「稳定登录号 + 版本号」，任何修订都会进位；LRG 刻意取消版本维度，用「冻结 + 另起新号」来吸收修订。两者的差别不是分支与主干，而是「可演进」与「不可演进」两种设计哲学。把 LRG 当作 RefSeq 的只读镜像，会低估它在编号纪律上的严格程度，也会误判它为何停更。

第二种：以为它是一份可以拿来跑分析的数据集。 LRG 里没有任何样本、没有变异、没有频率、没有表型。它提供的是一段坐标与一组建模结果。如果你要的是「十万个患者这个位点怎么变」，LRG 一个数字都给不了；它只回答「这段序列从哪个碱基数起、第 743 个是谁」。把它当变异数据库去检索，会得到一片空白。§4.4 的案例能说明这种误判是怎么发生的。

第三种：以为它可以替代 RefSeq 做全基因组注释。 这条误解与第一条方向相反：第一条把 LRG 看小，这一条把它看大。LRG 的建库是逐个申请的，不是扫描式生成的，因此它从来没有覆盖过全基因组，也不打算覆盖。反过来，RefSeq 也替代不了 LRG 的角色——RefSeq 的每条记录都要跟着修订走，无法承诺某条序列二十年不变。两者各自守着一个维度，缺了任何一个，临床报告流程里都会缺一块。

1.3 它能给到的与给不到的

你的需求	它给的	够不够
报告里那串变异写法十年后还能定位到同一段序列	不带版本号的 LRG_ 编号，固定段永不改动	够，这是它最强的能力
把旧报告换算出今天的坐标	可更新段里的装配体映射与 RefSeq/Ensembl 对照	基本够，需配合转换工具
查某个位点当前该用哪条转录本	固定段里有策展人选定的最少转录本，附 MANE 标记	部分够，记录冻结在 2021 年
一个基因的全部转录本	可更新段列出区域内全部转录本注释	够，但只到 2021 年的注释水平
变异的人群频率或致病性判读	无	不够，它不含任何变异数据
患者表型与基因型的对应	无	不够，它不含患者数据
覆盖你手上那个罕见病基因	只有当该位点有人申请过并建库时才有	常常不够，需先查清单
2021 年之后新发现的临床相关转录本	不会出现在固定段	不够，设计如此
一个能被所有系统直接解析的通用坐标	部分系统认，部分不认	不够，必须同时给等价 RefSeq 写法

这张表的重点是最后一行的反向提醒：LRG 的强项只有一项，弱项是一整片。凡是它给不到的，都不该指望它「顺便给一点」。一个只做坐标的系统，在坐标之外保持沉默，这是它的诚实之处，也是使用者在设计流程时必须预先补上的部分。

1.4 你的处境与它能帮到的事

你的处境	它能帮你什么	下一步该做什么
你手上有一批三年以上的旧报告，需要重新核对	若当时用了 LRG，直接查同一编号即可复现；若用了 NM_，可用对照表换算	先确认旧报告用的是哪套编号，再决定是直接复现还是换算
你要签发会进入终身随访流程的报告	给出一枚不会变质的坐标，避免若干年后被质疑	查目标基因是否已有 LRG，有则优先写 LRG 加 RefSeq 双坐标
你在做跨实验室的结果比对，各家写法不一致	提供共同参照，把不同写法收敛到一段固定序列上	建立内部映射表，把各实验室的 NM_ 写法统一换算
你在筛查一个罕见病基因，想找稳定基准	只有当该位点已建库时才有；未建库则无	先查清单，没有就转 MANE 或直接用带版本的 RefSeq
你要把历史变异数据迁移到 hg38	提供 GRCh37 与 GRCh38 双版本映射	核对新旧坐标是否一致，注意映射表冻结在 2021 年
你在搭知识库，需要一个不随时间漂移的主键	LRG 编号可作稳定主键，覆盖范围内不漂移	同时保存 RefSeq 写法作为交叉键，应对覆盖缺口
你要覆盖全基因组所有基因	给不了，只有上千条	转 MANE 或 RefSeq 全量
你想要最新的转录本注释	固定在 2021 年	转 GENCODE 或 Ensembl 当期版本

1.5 一句话判断

如果你要解决的问题是「这串变异写法二十年后还认不认得出」，LRG 是目前设计上最彻底的一种答案；如果你要解决的问题是「覆盖我手上这个基因」，它大概率帮不上，因为它 2021 年就停止新增了。先问清楚自己在解决哪一类问题，再决定要不要用。

1.6 不适合谁：四条边界

第一类：需要覆盖特定基因、但该基因没有 LRG 的人。 一千三百余条记录对应一千三百余个基因符号，相比之下人类蛋白编码基因在两万量级。这意味着大多数基因没有 LRG。若你的工作在某个具体位点上，第一步永远是查官方清单，而不是查文档。没查到，就意味着这条路到此为止——2021 年 3 月之后不再新增，等也不会等到。

第二类：需要最新转录本模型的人。 LRG 的固定段冻结在发布那一刻。若某个位点的转录本模型在 2021 年之后被大幅修订，LRG 的固定段不会跟着改。官方对此有明文机制：若固定段转录本的关键信息变了（起始密码子位置变了、编码外显子变了），只能另建新号，旧号继续有效但不再是首选。对追求最新的流程来说，这套机制等于把「过时」制度化地保留了下来，用起来要格外小心。

第三类：把 LRG 当作变异数据库的人。 记录里没有变异条目、没有频率、没有致病性分级，也没有表型。它是一套坐标系，不是一本病例集。用它做变异检索，会得到「查无此项」的错觉——不是数据缺失，是它压根不承担这个职能。

第四类：需要一个所有下游系统都认得的通用编号的人。 LRG 编号不是通用货币。部分工具链（Mutalyzer、VariantValidator、Ensembl VEP）支持它，很多实验室的信息系统、区域平台与部分商业软件并不解析 LRG_ 前缀。直接投递一个只含 LRG 编号的结果，可能在下游被当成非法格式丢弃。稳妥做法永远是双写：LRG 加等价 RefSeq。

§2 数据构成与规格

2.1 一条记录就是一份 XML，里面分两段

LRG 的物理形态很朴素：一条记录一个 XML 文件。文件名就是编号，例如 LRG_321.xml。文件内部按「会不会变」划成两个段，这个划分是整个资源的核心设计，理解它才能理解后面所有的行为。

固定段（fixed section）存放不动的部分：一段基因组 DNA 序列、报告临床变异所必需的最少转录本及其蛋白序列、以及一套 LRG 专属的外显子编号。官方 FAQ 的原话是：固定段里的参考序列一旦 LRG 转为公开就不得更改。

可更新段（updatable section）存放会动的部分：与当前及上一版基因组装配体的映射信息、区域内全部转录本与重叠基因的注释、以及社群提交的其他信息（例如旧的外显子编号与氨基酸编号体系）。这一段由脚本每周自动刷新，公开记录与待定记录都在刷新之列。

这个二分法解决了一个看似无解的张力：坐标系要稳，注释要新。把两件事塞进同一个文件的两个段里，各按各的节奏走——固定段冻结，可更新段每周刷。使用者要稳的时候读上半段，要新的时候读下半段，互不干扰。

段落	内容	是否会变	刷新方式
固定段 · 基因组序列	该位点的基因组 DNA 序列与坐标	永不	无
固定段 · 转录本	报告临床变异所必需的最少转录本	永不	无
固定段 · 蛋白	上述转录本的翻译产物	永不	无
固定段 · 外显子编号	LRG 专属的连续外显子编号	永不	无
可更新段 · 映射	与 GRCh37、GRCh38 的坐标对应	随装配体升级重算	每周脚本
可更新段 · 注释	区域内全部转录本与重叠基因	跟随 RefSeq/GENCODE	每周脚本
可更新段 · 旧编号	社群提交的遗留外显子与氨基酸编号	随社群提交	每周脚本
可更新段 · 替代指向	被新记录替代时的指向字段	事件驱动	随发布
可更新段 · MANE 标记	转录本是否为 MANE Select	跟随 MANE 计划	每周脚本

2.2 字段与记录的完整字典

下表按「这条信息干什么用」组织，而不是按 XML 的标签顺序。因为使用者关心的往往是用途，不是嵌套层级。

信息类别	典型形式	出现在哪一段	用途	稳定性
LRG 编号	LRG_321	文件级	记录主键，报告里写的前缀	永不改动
转录本编号	t1、t2 …	固定段	拼在 LRG 编号后表示具体转录本	永不改动
蛋白编号	p1、p2 …	固定段	拼在 LRG 编号后表示具体蛋白	永不改动
HGNC 符号	TP53	清单与 XML	与基因名体系对接	随 HGNC 更新
基因组坐标	染色体、起止、链向	清单与固定段	定位到装配体上的区间	随装配体变
RefSeqGene 登录号	NG_017013.2	固定段与可更新段	与 RefSeq 系对接的桥梁	带版本，会变
RefSeq 转录本	NM_000546.5	对照表	换算到 mRNA 编号	带版本，会变
RefSeq 蛋白	NP_000537.3	对照表	换算到蛋白编号	带版本，会变
Ensembl 转录本	ENST00000610538.4	对照表	换算到 Ensembl 体系	带版本，会变
CCDS 编号	CCDS11118.1	对照表	与共识编码序列集对接	带版本
外显子坐标串	逗号分隔的区间列表	清单与固定段	逐外显子定位	固定段内不变
编码区起止	CDS 起点与终点	清单与固定段	换算 c. 坐标的基准	固定段内不变
MANE 来源标记	MANE-select、MANE-plus	可更新段	标注该转录本是否 MANE 选定	跟随 MANE 计划
维护状态	public、pending、suppressed	清单与目录	判断记录是否可正式使用	事件驱动
被替代指向	superceded_by	可更新段	指向替代它的新记录	事件驱动

有两处需要特别留意。第一，NG_、NM_、NP_、ENST 这些对照编号全部带版本号，而 LRG 编号不带——这意味着对照表本身是会过期的。第二，清单文件里给出的只是坐标与状态，真正的对照关系在另一张交叉引用表里，两张表要一起用才完整。

2.3 一条记录的完整解剖

以 TP53 为例，把一条记录拆开看。下面这段取自官方 FTP 根目录下的 LRG_321.xml，只保留可读的部分、略去了序列正文，标签名与属性名都是原样。

#-- LRG_321.xml 摘录（schema 1.10，略去序列正文）
<lrg schema_version="1.10">
  <fixed_annotation>
    <id>LRG_321</id>
    <hgnc_id>11998</hgnc_id>
    <sequence_source>NG_017013.2</sequence_source>
    <mapping coord_system="GRCh37.p13" other_name="17"
             other_start="7563097" other_end="7595868"
             type="other_assembly"/>
    <mapping coord_system="GRCh38.p13" other_name="17"
             other_start="7659779" other_end="7692550"
             type="main_assembly"/>
    <transcript name="t1">
      <coordinates coord_system="LRG_321" start="5001" end="24149" strand="1"/>
      <exon label="1">
        <coordinates coord_system="LRG_321" start="5001" end="5119" strand="1"/>
        <coordinates coord_system="LRG_321t1" start="1" end="119"/>
      </exon>
      <exon label="2a">
        <coordinates coord_system="LRG_321" start="15929" end="16030" strand="1"/>
        <coordinates coord_system="LRG_321t1" start="175" end="276"/>
        <coordinates coord_system="LRG_321p1" start="1" end="25"/>
      </exon>
      <coding_region>
        <coordinates coord_system="LRG_321c" start="16030" end="24019" strand="1"/>
        <coordinates coord_system="LRG_321p1" start="1" end="393"/>
      </coding_region>
    </transcript>
    <transcript name="t2">
      <coordinates coord_system="LRG_321" start="5001" end="24149" strand="1"/>
    </transcript>
  </fixed_annotation>
  <updatable_annotation>
    <annotation_set type="requester"/>
    <annotation_set type="lrg"/>
    <annotation_set type="ncbi">
      <mapping coord_system="NM_000546.5" other_start="1" other_end="2591"/>
      <mapping coord_system="NM_000546.6" other_start="1" other_end="2512"/>
    </annotation_set>
    <annotation_set type="ensembl">
      <mapping coord_system="ENST00000269305.9" other_start="1"/>
    </annotation_set>
    <annotation_set type="lsdb">
      <source name="IARC TP53 Mutation Database"/>
    </annotation_set>
  </updatable_annotation>
</lrg>

从这段结构里能读出五件事。其一，lrg 根节点带 schema_version 字段，这条记录声明的是 1.10，版本兼容性可以从文件本身判断。其二，固定段只给 LRG_321、t1、t2 这类不带外部版本号的编号，基因组来源 NG_017013.2 另列在 sequence_source 里，说明「取自哪一版 RefSeqGene」被记下了，但 LRG 自己不继承那个版本。其三，同一个 mapping 标签既用于装配体（GRCh38.p13），也用于转录本（NM_000546.5），靠 type 区分，解析时最容易在这里混淆。其四，外显子标签允许字母后缀，2a 这种写法用来表达同一段基因组被切成的不同转录本片段。其五，可更新段的 ncbi 注释集同时挂着 NM_000546.5 与 NM_000546.6——版本问题的实证就在文件里，下文再展开。

2.4 规模：一千三百余条，编号预留到一千四百多

官方 2021 年 3 月 31 日第 810 版发布说明写得很清楚：1325 条 LRG 记录，0 条待定记录。清单文件里同样是一千三百余行，状态全部为 public。

但编号并不是连号的。清单里出现的最大编号是 LRG_1431，而记录总数是一千三百余条，中间的差额是一百来个空号。空号从 LRG_861 开始出现一段较长连续区间，另有一些零星缺口。官方没有解释这些空号的具体成因，从目录结构只能推断一部分：suppressed 目录里放着 LRG_861 这一条记录，说明存在「编号被占用后记录被撤下」的情形。

规模指标	数值	口径
公开记录数	1,325 条	第 810 版发布说明与清单一致
待定记录数	0 条	同版发布说明
被撤下的记录	1 条（LRG_861）	suppressed 目录内文件
最大编号	LRG_1431	清单内出现
编号空号	106 个	最大编号减记录数
对应基因符号数	与记录数相同	一条记录一个基因符号
固定段转录本总数	1,641 条	转录本清单行数
固定段蛋白总数	1,616 条	蛋白清单行数
记录内转录本数量	多数为一条（一千余条记录）	转录本清单聚合
记录内转录本最多	15 条	单条记录上限
记录内转录本为 2 条	185 条记录	转录本清单聚合
记录内转录本 ≥ 3 条	49 条记录	转录本清单聚合
出现在 Ensembl 的 LRG	862 条	官方 lrgs_in_ensembl 清单

转录本的分布想说明一件事：官方 FAQ 写「我们的目标是每个位点只放一条转录本，但有时为了把该位点的全部变异都描述清楚，不得不放多于一条」。数据印证了这个说法——八成以上的记录确实只有一条，剩下近两成需要多条。TP53 是极端个例，它放了 8 条转录本，因为该位点的不同转录本对应不同的临床议题。

2.5 结构：编号怎么拼，后缀怎么读

LRG 的编号系统简单到只需要一分钟就能讲完，但有两个细节几乎所有人都会记错。

编号由两部分组成：LRG_ 前缀加一个整数。整数是全局顺序号，不表示基因、染色体或任何生物学含义，纯粹是建库顺序。LRG_1 是 COL1A1，LRG_13 是 CALCA，LRG_321 是 TP53，这些数字之间没有可推演的关系。

后缀只有两种。转录本用 t 加序号，蛋白用 p 加序号。LRG_321t2 表示这条记录的第二个固定转录本（TP53 的 t1 是 NM_000546 对应那条，t2 是另一条），LRG_321p1 表示这条记录的第一个固定蛋白。写成变异时，坐标前缀直接接在蛋白或转录本编号后面：基因组层面是 LRG_321:g.，转录本层面是 LRG_321t2:c.，蛋白层面是 LRG_321p1:p.。

第一个易错点：t 与 p 的序号不保证一一对应。 这是最反直觉的一条。TP53 的 LRG_321 里，RefSeq 编号为 NM_000546.5 的那条转录本被定为 t1，它的蛋白确实是 p1；但编号里排第三的 NM_001126114.2 对应的是 t3 与 p3，编号里排第四的 NM_001126113.2 对应的是 t4 与 p4。多数情况下 t 与 p 的序号碰巧一致，于是「t1 对 p1」这个直觉在使用者中间流传开来；一旦遇到序号错位、或遇到只对部分转录本建了蛋白的记录，直觉就会失效。结论是同一个：写蛋白行必须逐条查表，不能按序号推。

第二个易错点：LRG 专属外显子编号不等于惯用编号。 官方 FAQ 说明，LRG 专属外显子编号以固定段里的转录本为准，从 5′ 端到 3′ 端连续编号，然后再套用到各条转录本上。这与临床惯用的历史外显子编号可能不同——尤其是某些基因在历史上有过重新编号的争议。旧编号被放在可更新段里作为参照，正说明两者不是一回事。

后缀形式	含义	示例	使用场景
无后缀	基因组 DNA 坐标	LRG_321:g.7659800A>G	基因组层面的变异描述
t + 序号	转录本 c. 坐标	LRG_321t1:c.743G>A	报告中最常用的形式
p + 序号	蛋白 p. 坐标	LRG_321p1:p.Arg248Gln	蛋白功能影响的描述
t 与 p 的对应	需要查表，不保证同号	t3 与 p3、t4 与 p4 各自成对	写双坐标时必须核对
外显子编号	LRG 专属连续编号	外显子 1 至 11	与惯用编号可能不一致

2.6 记录内转录本与蛋白的数量分布

记录内固定转录本数量	记录数	典型情形
1 条	一千余	绝大多数基因，一条转录本即可覆盖全部报告需求
2 条	185	存在临床上必须区分的选择性剪接
3 条	31	转录本较多且各有独立临床意义
4 条	13	少数复杂位点
5 条	4	极少数复杂位点
15 条	1	单条记录的上限，属于特例
合计	与公开记录总数一致	—

蛋白记录比转录本略少（1,616 对 1,641），差额来自部分转录本属于非编码或未给出独立蛋白的情形。这个差额不大，但足以提醒：转录本编号与蛋白编号是两套独立的序列，不能互推。

§3 身份层：一枚不带版本号的铭牌

3.1 版本号到底带来了什么问题

要理解 LRG 为什么值得单独存在，得先把版本号的代价讲透。INSDC 体系给序列编号的方式是「稳定登录号 + 版本号」，NM_000546 是登录号，.6 是版本。任何修订都会让版本进位，这是数据库管理的常规做法：不改登录号，改版本，既保住了引用关系，又忠实地反映了内容变化。

问题出在使用端。改版本对数据库是记录了一次修订，对报告却是一次坐标地震。官方 FAQ 对此的表述直指要害：序列的版本在出版物里经常不被报告，因此当参考序列的版本号大于 1 时，使用者在解读变异后果时就会遇到不确定性。LRG 的应对是把版本这个维度整个拿掉：没有版本，也就不存在「引用时省略版本」与「两版坐标不一致」这两个问题。

这句话里藏着两个独立的问题。一个是引用时的省略：论文里常写 NM_000546:c.743G>A，省掉了版本号，检索者不知道作者指的是哪一版。一个是版本本身的含义：即便作者写了 .5，手上的数据库可能已经是 .6，而两边同一个 c.743 未必是同一个碱基。

这两个问题不是假想。LRG_321 的可更新段里，ncbi 注释集同时列着 NM_000546.5 与 NM_000546.6，两条映射各自带着自己的长度：前者 2591，后者 2512。同一条序列的两个版本差了七十余个碱基，累计到编码区的第 743 位附近，位置是否仍然对齐，无法靠直觉判断。一份只写 NM_000546 的报告，若被检索系统归一到新版本，落点就可能偏离；一份只写 NM_000546.5 的报告，能对上旧版本，但下游系统是否保留旧版本、是否自动升级，各家做法不一。

3.2 冻结而不是修订，是代价也是承诺

「固定段永不改动」这句话读起来像一句技术说明，实际上是一份对外承诺。它承诺的内容是：你今天写下的 LRG_321t1:c.743G>A，在任何未来时刻，用任何工具，都能定位到同一个碱基。

设计选择	直接后果	使用者的应对
固定段冻结	记录永不失效，也永不被修正	接受瑕疵，或改用替代记录
不设版本号	引用时无需写版本，也无法表达「第几版」	以编号本身为唯一身份
修订时另起新号	同一基因可能出现多条并存记录	查 superceded_by 判断首选
旧号不撤销	历史报告永远可复现	不要因为「有更新的」就否定旧写法
可更新段每周刷新	注释能跟上，序列不动	读注释看下半段，读序列看上半段

3.3 编号是一枚铭牌，坐标是铭牌上的地址

有个容易混淆的地方：LRG 编号稳定，不代表 LRG 的坐标稳定。同一段序列，在 GRCh37 上的位置与在 GRCh38 上的位置不同。LRG 记录里同时保存两套装配体的映射，正是因为这个原因。所以正确的理解是分层的：编号层是铭牌，永不松动；坐标层是铭牌上写的地址，会随地图重绘。LRG_321t1:c.743G>A 之所以比基因组坐标更稳，是因为 c. 是相对转录本自身数出来的，不依赖装配体；但它仍依赖固定段里的外显子划分。这个分层解释了 LRG 为何能同时做到「坐标稳定」与「坐标随装配体更新」——它稳的不是坐标，是坐标所依附的那段序列。

§4 特征层：稳定性这门手艺的三个断点

4.1 第一个断点：序列对了，坐标未必对

LRG 的稳定性建立在「序列不变」上，但临床报告要的不只是序列，还有位置。位置这件事在 LRG 里由两套东西定义：基因组坐标（依赖装配体）与转录本坐标（依赖外显子划分）。前者会随装配体升级而重算，后者随记录冻结。

官方对此的说明很坦率：一旦新装配体发布，全部 LRG 的映射信息与注释都会更新到新装配体，每条记录里同时包含当前与上一个装配体的映射。这意味着基因组坐标这一层始终在动，只不过动的方向被明确记录了下来。

具体到操作上，LRG_321 的固定段里并排放着两条装配体映射：GRCh37.p13 对应 7563097 至 7595868，GRCh38.p13 对应 7659779 至 7692550。两个区间长度相同（同为三万二千余碱基），起点却差了九万六千余碱基。这不是数据错了，而是同一条序列在两张地图上的不同地址。若有人把 hg37 的区间当成 hg38 的去写，报告上的位置会偏出十万碱基量级，落点完全错误。

4.2 第二个断点：冻结的代价会在多年后显形

冻结的代价不是当天显形的，而是在若干年后慢慢浮现。设想某条 LRG 在 2015 年发布，固定段选定的转录本在当时是最佳选择。五年后，新的长读长测序证据表明该转录本的起始密码子上游还有一个可用的起始位点，编码区因此前移。此时 LRG 无法修改，只能另建新号。

官方 FAQ 对这一点的表述相当冷静：一旦 LRG 公开，固定段里的转录本就不能被移除；这意味着若关于该转录本的认识发生重大变化，就无法在记录里注明。唯一的办法是另建一份包含更新后转录本的新记录。

4.3 第三个断点：停更之后的注释老化

LRG 的可更新段至今仍在按设计刷新——前提是刷新脚本仍在运行、上游 RefSeq 与 GENCODE 仍在产出被引用的登录号。但记录集合本身冻结在 2021 年 3 月 31 日，这个日期之后新增的临床相关转录本、新增的重叠基因、新修订的 MANE 选定，都不会以「新记录」的形式进入 LRG。

这说明一个容易被忽略的细节：停更指的是「不再有新记录」，不是「文件不再变化」。LRG_321 的可更新段里同时列着 NM_000546.5 与 NM_000546.6，后者显然是发布之后才被加进去的，否则当年不可能同时给出两个版本。所以读这份记录的人面对的是两种时间：固定段停在发布那一刻，可更新段停在一个更晚的时刻，而整个集合停在不接受新申请的那一刻。三个时刻不是同一个。

对把 LRG 当作长期主键的系统，这是一个必须提前设计的风险。稳妥的做法是把 LRG 编号当作历史锚点，把 RefSeq 或 MANE 编号当作流动指针，两者在数据库里同时保存：前者用于对上历史，后者用于跟上当下。指针会变，锚点不变，两者分工明确，查询时先按锚点找到那一批旧记录，再按指针去取当前注释。

4.4 案例：TP53 的一行报告，两套编号，十一年

下面这个案例贯穿全文。前面三个断点讲的是原则，这个案例讲后果：三处断点在同一行报告上同时显形，才看得出 LRG 究竟挡掉了哪一部分风险。

设想 2015 年签发的一份肿瘤胚系检测报告，结论行写的是 LRG_321t1:c.743G>A，同一行下方附了等价的 RefSeq 写法 NM_000546.5:c.743G>A，蛋白层面写的是 LRG_321p1:p.Arg248Gln。

先说这行字在 2015 年为什么这么写。LRG_321 是 TP53 的记录编号，t1 是固定段里与 NM_000546.5 对应的那条转录本，p1 是它的蛋白。这一行当年为什么容易被写错？因为写报告的人若按「t1 对 p1、t2 对 p2」的直觉去套其余转录本，在 LRG_321 上恰好蒙对了，换到序号错位的记录上就会错；反过来，若他知道 t 与 p 是两套独立编号，就不会去套，而是查表。

再说这行字在多年之后怎么用。这一步有三个可以复核的证据。第一，官方交叉引用表里，LRG_321 与 NM_000546.5 的绑定是固定的，表里写着 NM_000546.5，不会因为上游修订而改写。第二，LRG_321 的 XML 可更新段里，NM_000546.6 已经与 NM_000546.5 并列出现，用官方记录自身的文件就能证明「新版本确实来过」。第三，两条映射的长度分别是 2591 与 2512，差了七十余个碱基——这是两条长度不同的序列，不是同一个东西改了名字。

LRG_321t1:c.743G>A 这一半不受影响。它指向的序列被冻结在记录里，c.743 永远是那个碱基。这就是 §4.4 的案例要说明的核心：稳定性不是「所有写法都稳定」，而是「有一种写法被设计成稳定」。它稳定的边界也很清楚——编号与 c. 坐标稳，但若几年后有人拿 LRG_321 的基因组坐标去检索，得到的仍是 2021 年那张映射表给出的区间，而不是任何更新的重排结果。

报告要素	2015 年写法	今天复核时的风险	稳定写法
基因组坐标	NG_017013.2:g. 加位置	NG_ 带版本，检索时易被归一	LRG_321:g. 加位置
转录本坐标	NM_000546.5:c.743G>A	版本可对，但系统常自动升级	LRG_321t1:c.743G>A
蛋白坐标	NP_000537.3:p.Arg248Gln	NP_ 带版本，换算易错位	LRG_321p1:p.Arg248Gln
外显子表述	惯用外显子编号	重编号史导致歧义	LRG 专属外显子编号
基因名	TP53	相对稳定，但别名多	TP53 加 HGNC 编号

§4.4 的案例还有第二层用途：它解释了为什么双写是必要的。只写 LRG，下游可能不认；只写 NM_，多年后可能漂移。两套一起写，等于同时买了「当下可用」与「长期可查」两份保险。后面凡是讨论报告规范的地方，都会回到这个案例。

4.5 稳定性这件事，LRG 做到了几成

把三个断点合起来评估，可以给出一个分维度的判断。

稳定性维度	LRG 的表现	说明
编号不漂移	完整做到	无版本号，编号本身即身份
序列不漂移	完整做到	固定段永不改动
转录本坐标不漂移	完整做到	c. 坐标相对固定段数出
基因组坐标不漂移	未做到，但有补偿	随装配体重算，旧映射保留
外显子编号不歧义	部分做到	专属编号可消歧，但与惯用并存
与当代认识同步	未做到	集合冻结在 2021 年
跨系统通用	部分做到	部分工具支持，非通用货币

七项里三项完整做到，两项部分做到，两项未做到。这个成绩单说明 LRG 不是「全面的稳定性方案」，而是「在序列与编号这一层做到了极致、在其他层明确不承诺」的方案。判断它是否适合自己，关键是看自己最怕哪一维漂移。

§5 取数层：没有 API，只有一份目录和几张清单

5.1 入口长什么样

LRG 没有专门的数据 API。官方站点的搜索页靠前端脚本读两个静态 JSON 索引完成检索，真正的数据都在 EMBL-EBI 的 FTP 目录里。这个目录名是 lrgex 而不是 lrg——按直觉拼接的 pub/databases/lrg/ 会返回 404，这是第一次访问时最常见的浪费。

目录内容可分成四类：单条记录、清单表、序列文件、状态子目录。四类各有各的用途，混用会很别扭。想按基因查记录，走清单；想读一条记录的完整结构，走单条 XML；想批量拿序列，走 FASTA；想判断某条记录是否可用，看状态子目录与清单里的状态列。

目录或文件	路径	内容	形式
单条记录	目录根下 LRG_<编号>.xml	每条 LRG 一份 XML	XML
记录清单	list_LRGs_GRCh38.txt	编号、基因、状态、坐标	TSV
旧装配体清单	list_LRGs_GRCh37.txt	同上，GRCh37 坐标	TSV
转录本清单	list_LRGs_transcripts_GRCh38.txt	转录本坐标、外显子串、CDS	TSV
蛋白清单	list_LRGs_proteins_RefSeq.txt	蛋白与转录本对应	TSV
交叉引用表	list_LRGs_transcripts_xrefs.txt	RefSeq、Ensembl、CCDS 对照	TSV
Ensembl 清单	lrgs_in_ensembl.txt	已进入 Ensembl 的 LRG 编号	纯文本
索引 JSON	data_files/lrg_index.json	站内搜索用的索引	JSON
FASTA 序列	fasta/	记录序列	FASTA
已撤下记录	suppressed/	被撤下的记录	XML
发布说明	relnotes.txt	逐版变更记录	纯文本
XML schema	SCHEMA_1_9_ARCHIVE/ 等	各版本 schema 存档	XSD

5.2 清单文件怎么读

清单是 TSV，首行是注释形式的表头，以 # 开头，字段依次是编号、基因符号、状态、染色体、起点、终点、链向。解析时要注意两件事：表头以 # 开头，不能直接当数据行；某条染色体的值可能是字母，转换成整数会失败。

下面这段代码用 Python 标准库读清单，按状态计数，并算出各记录基因组区间的长度中位数。它不依赖任何第三方包，可以直接运行。

#-- 读官方清单，统计记录数与区间长度
import urllib.request, statistics, collections

URL = "https://ftp.ebi.ac.uk/pub/databases/lrgex/list_LRGs_GRCh38.txt"
raw = urllib.request.urlopen(URL, timeout=60).read().decode("utf-8")

status = collections.Counter()
lengths = []
for line in raw.splitlines():
    if not line.strip() or line.startswith("#"):
        continue
    f = line.split("\t")
    status[f[2]] += 1
    #-- 起点与终点都在第 5、6 列；性染色体以外的记录可直接相减
    try:
        lengths.append(int(f[5]) - int(f[4]) + 1)
    except ValueError:
        continue

print("记录数", sum(status.values()))
print("状态分布", dict(status))
print("区间长度中位数", statistics.median(lengths))
print("最短", min(lengths), "最长", max(lengths))

这段代码输出四个结果：记录总数、状态分布、区间长度中位数、以及最短与最长区间。记录总数与状态分布可以拿官方发布说明直接对照，是校验下载是否完整最省事的一步；长度中位数与极值则只能由清单算出来，官方没有公布这几个数，因此它们属于本文推算，引用时要注明口径。

5.3 交叉引用表怎么用

清单只给坐标，跨联盟编号在另一张表里。交叉引用表同样是 TSV，字段依次是 LRG 编号、基因符号、RefSeqGene 登录号、转录本后缀、RefSeq 转录本、Ensembl 转录本、CCDS 编号。要回答「这个 NM_ 编号对应哪条 LRG」，靠的是这张表。

有一个细节要留意：Ensembl 那一列存在用短横线表示「无对应」的情况。这不是数据缺失，而是确实没有建立对应关系。统计时若把短横线当作有效值，会得出错误的覆盖结论。

#-- 用交叉引用表反查 NM_ 编号对应的 LRG 转录本
import urllib.request

URL = "https://ftp.ebi.ac.uk/pub/databases/lrgex/list_LRGs_transcripts_xrefs.txt"
raw = urllib.request.urlopen(URL, timeout=60).read().decode("utf-8")

target = "NM_000546"
hits = []
for line in raw.splitlines():
    if not line.strip() or line.startswith("#"):
        continue
    f = line.split("\t")
    nm = f[4]
    #-- 检索时忽略版本号：去掉最后一个点之后的部分再比较
    if nm.split(".")[0] == target:
        hits.append({
            "lrg": f[0], "gene": f[1], "rsg": f[2],
            "tx": f[3], "nm": nm, "enst": f[5], "ccds": f[6],
        })

for h in hits:
    print(h["lrg"] + h["tx"], "->", h["nm"], "|", h["enst"])

运行后输出的是该 RefSeq 编号在 LRG 里的全部落点。若输出为空，说明该基因没有 LRG，也就没有必要继续往下走。

5.4 单条记录怎么解析

单条 XML 的嵌套不深，用标准库的 XML 解析器就能读。下面这段读出一条记录的全部装配体映射与转录本标签，用来做坐标核对。

#-- 解析单条 LRG 记录：列出装配体映射与各转录本引用的 RefSeq 版本
import urllib.request
import xml.etree.ElementTree as ET

#-- 单条 XML 放在 FTP 根目录，不在 data_files 子目录里
URL = "https://ftp.ebi.ac.uk/pub/databases/lrgex/LRG_321.xml"
root = ET.fromstring(urllib.request.urlopen(URL, timeout=60).read())

#-- 固定段：装配体映射与转录本标签
for m in root.iter("mapping"):
    if m.get("type", "").endswith("assembly"):
        print("assembly", m.get("coord_system"),
              m.get("other_start"), m.get("other_end"))

for t in root.find("fixed_annotation").findall("transcript"):
    print("transcript", t.get("name"))

#-- 可更新段：ncbi 注释集里并列的 RefSeq 版本
for ann in root.iter("annotation_set"):
    if ann.get("type") == "ncbi":
        for m in ann.findall("mapping"):
            print("refseq", m.get("coord_system"),
                  "len", m.get("other_end"))

这段代码打印三类行：装配体映射、转录本标签、以及该记录引用的 RefSeq 版本清单。最后一行输出是重点——同一条 LRG 记录的注释里同时挂着 NM_000546.5 与 NM_000546.6，两个版本并列。这不是 XML 写错了，而是可更新段每周刷新留下的痕迹：上游 RefSeq 修订后新版本被加进来，旧版本因仍被引用而保留。这段输出本身就是「版本会变、LRG 不变」最直接的证据。

5.5 坐标换算怎么走

把旧编号换算到 LRG，或者把 LRG 换算到旧编号，靠两条路径。第一条是查交叉引用表，适合批量、离线、不需要考虑装配体的情况。第二条是调用在线校验工具，适合单条核对，因为这类工具会把坐标、外显子边界与 HGVS 语法一起检查。

#-- 用 VariantValidator 的公开接口校验一条 LRG 写法的语法与坐标
#-- 该接口返回 JSON，其中 warnings 与 errors 字段用于判断写法是否成立
curl -sS --max-time 30 \
  "https://rest.variantvalidator.org/VariantValidator/variantvalidator/GRCh38/LRG_321t1%3Ac.743G%3EA/all" \
  -o lrg_321_check.json

python3 -c "import json;d=json.load(open('lrg_321_check.json'));\
print(list(d.keys())[:12])"

这条命令的意义在于把「写法是否能被解析」这件事交给工具判，而不是靠人眼。LRG 编号能否被识别、c.743 是否落在编码区内、G>A 是否与参考碱基一致，工具会一次给出结论。

5.6 取数时容易踩的四个坑

坑	表现	应对
目录名拼错	pub/databases/lrg/ 返回 404	用 lrgex，不是 lrg
把 # 行当数据	解析报错或统计多一行	过滤以 # 开头的行
把短横线当有效值	得出 Ensembl 覆盖 100% 的错误结论	把 - 视作无对应
忽略命名空间	XML 解析后一条记录都取不到	按 localname 匹配而非全名

四个坑里有三个是解析层面的，一个是路径层面的。它们都不难，但都会在第一次上手时耗费时间。把它们写进团队的上手文档，比每次重新踩一遍划算。

§6 与库内条目的关系

6.1 关系图谱

LRG 在数据生态里的位置不是「一个数据集」，而是「一组数据集共同的坐标基准」。它和几类资源有明确的分工关系，理解这些关系比记住它的字段更重要。

相关资源	关系类型	LRG 的角色	使用建议
RefSeq / RefSeqGene	上游来源	取用其序列并加以冻结	需要最新注释时用 RefSeq，需要稳定坐标时用 LRG
Ensembl / GENCODE	平行注释源	提供可更新段的转录本注释来源	想看当期基因结构时用 Ensembl
MANE	继任者	被官方推荐在有 MANE Select 时替代	新项目优先 MANE，历史项目保留 LRG
HGNC	命名上游	记录里的基因符号取自 HGNC	基因名歧义时以 HGNC 编号为准
ClinVar 等变异库	消费方	提供坐标，不提供变异	变异检索用变异库，坐标核对用 LRG
位点特异性数据库	共建方	策展人参与申请与审核	罕见病位点常由这类库发起建库
HGVS 命名规范	规范依托	编号写法遵循 HGVS	语法校验交给 Mutalyzer 一类工具
基因组浏览器	展示层	作为独立轨道呈现	Ensembl、NCBI、UCSC 三处均可查

这张表要传递的判断是：LRG 处在上游（取序列）与下游（变异报告）之间，它自己既不是起点也不是终点。它的价值全在「中间那一层被钉住」。一旦上下游都改用 MANE，这一层的必要性就下降了——这正是它停更的背景。

6.2 检索路径

要在库内或外部找到与 LRG 相关的内容，有四条常用路径，各有适用场景。

路径	起点	适合做什么	局限
按基因符号查	官方站搜索页输入 TP53	快速确认该基因是否有 LRG	站内搜索依赖前端脚本，抓取需走索引 JSON
按 LRG 编号查	直接输入 LRG_321 或纯数字 321	精确打开一条记录	编号不连号，无法按数字区间批量推
按 RefSeq 编号查	输入 NM_000546 去掉版本	反查记录	需借助交叉引用表或站内搜索
按状态查	在搜索里输入 public 或 pending	盘点可用记录	2021 年后再无 pending

四条路径里最实用的其实是第一条与第三条的组合：先按基因名确认有无，再按 RefSeq 编号锁定转录本。第四条路径在 2021 年之后基本上只能查到 public，因为待定记录已经是零。

6.3 与 MANE 的分工要讲清

既然官方把 MANE 列为推荐替代，就得说清楚两者的分工边界，否则很容易在两个方案之间来回摇摆。

MANE 的目标是「每个蛋白编码位点一条被两联盟共同认可的转录本」，方法是算法加人工共识，特点是与 RefSeq、Ensembl 逐碱基一致，且持续更新。它解决的是「该用哪条转录本」这个选择问题，不解决「这条序列会不会变」这个问题——MANE Select 转录本本身也带版本号，会随两联盟的修订而进位。

LRG 解决的是后者。它不追求覆盖，也不追求共识的广度，只追求被它覆盖的那一小块绝对不动。

于是分工就清楚了：新报告的转录本选择用 MANE，会进入长期存档的关键结果可以额外记一个 LRG 编号（若该位点有）。两者不冲突，甚至可以叠在同一行报告里。

需求	MANE 能否满足	LRG 能否满足	建议
这个基因该用哪条转录本	能，且覆盖全基因组	只在千余位点有	以 MANE 为准
这条转录本会不会改	会，随版本演进	不会，冻结	需要长期稳定时查 LRG
2021 年之后的新位点	能	不能	只能用 MANE
历史报告的坐标复原	部分	能	用 LRG 回查
与 Ensembl 逐碱基一致	能	未保证	跨联盟比对用 MANE

§7 质量评估与局限性

7.0 阅读本节前的一个前置校正

在给出评分之前，必须先校正一个很容易发生的误判：把「停更」等同于「质量下降」。

LRG 的记录集合在 2021 年 3 月 31 日之后不再新增，这是事实。但停更的原因不是质量出了问题，而是它想解决的问题被一个更有效率的方案接走了——官方自己在每一页顶部写着，有 MANE Select 的基因优先用 MANE。这是主动退场，不是被动崩盘。

区分的意义在于评估方式。若把停更当成质量扣分项，评分逻辑会变成「越新的越好」，从而错过一个关键判断：被它冻住的那一千三百余条记录，其固定段的可靠性并未因停更而降低。一条 2016 年发布的 LRG，今天读它，固定段与当年逐字节相同。这正是它设计时想要的。

真正需要扣分的是另外两处：覆盖面窄，以及在 2021 年之后与当代认识逐步脱节。这两处是真局限，且都写在使用者能预期的地方，不是隐藏缺陷。

所以本节的评分针对的是「作为一个仍在服役的坐标系统」来打的，不是针对「作为一个活跃项目」来打的。评分口径说明清楚，分数才有意义。

7.1 五维评分

维度	分数	依据	扣分原因
稳定性	9	固定段永不改动，编号无版本	基因组坐标仍随装配体重算
一致性	8	每条记录经人工审校与专家复核	外显子编号与惯用编号并存，易混用
可接入性	7	FTP 开放下载，TSV 与 XML 结构清晰	无正式 API，站内搜索依赖前端
覆盖面	3	一千三百余位点	相对全基因组极小，且已停止新增
时效性	3	集合冻结在 2021 年 3 月	后续新的临床转录本不进入固定段
综合	6.0	稳定性一流，覆盖面与时效性弱	定位为「历史锚点」而非「通用基准」

同一套判断换到 DAIMS 框架下再看一遍，五维各五分制，看的是它作为一份可流通数据资源的成色。

DAIMS 维度	分数	判断依据
可发现性	4 / 5	三大基因组浏览器可检索，FTP 目录结构清晰，另有静态索引供程序化查询
可访问性	5 / 5	无申请门槛，无登录要求，直接 HTTP 下载，许可明确
可用性	4 / 5	XML 有公开 schema，TSV 字段稳定，可被脚本直接消费；无正式 API 是唯一缺口
互操作性	3 / 5	与 RefSeq、Ensembl 有对照表，但部分记录缺 Ensembl 对应，且外显子编号自成一套
可复用性	3 / 5	序列可自由复用，但集合冻结，新位点永远拿不到对应编号

可访问性满分是它最硬的一项：一个临床级参考资源能做到零门槛公开下载，本身就是治理上的选择。互操作性与可复用性各三分，短板也很清楚——前者卡在联盟映射的缺口上，后者卡在停更上。这两项恰好是选型时最需要提前判断的两项。

7.2 一致性：人工策展做到了什么程度

一致性这一维给到八分，依据是官方披露的建库流程。流程分七步，核心是把「选哪条转录本」这件事从个体判断变成集体判断。

第一步由申请人提出需求，可以是诊断机构、研究团队、位点特异性数据库策展人。第二步生成待定记录，此时记录尚未定稿，仍可变。第三步由 EMBL-EBI 的科学家逐条人工审校：先把 RefSeqGene 与 GRCh38 逐位比对，发现不一致就查等位基因频率，若参考基因组上的等位基因在所有人群中的频率不超过百分之五，就提交给基因组参考联盟请求复核；再用人工审阅区域内全部已知转录本的支持证据与社群使用情况。第四步与第五步联系该位点的专家征求意见。最后两步才定稿发布。

7.3 已知的、可枚举的偏差

偏差不是缺陷的委婉说法，而是有方向的系统性偏离。LRG 至少存在四处可枚举的偏差。

偏差	方向	成因	后果
位点选择偏差	偏向已被社群关注的基因	建库需主动申请	冷门基因系统性缺席
时间偏差	偏向 2021 年前的注释水平	集合冻结	新发现转录本无法进入固定段
编号连续性偏差	编号不连号，存在空号	部分编号被撤下或未发布	按数字区间推记录数会错
联盟映射偏差	部分记录无 Ensembl 对应	两联盟注释差异未完全收敛	跨联盟换算需另找工具

第一条偏差最值得说明。LRG 的建库起点是「有人来要」，不是「系统扫描全基因组挑出临床相关位点」。这意味着被建库的位点反映了 2008 年至 2021 年间社群关注的分布：肿瘤易感基因、遗传性心血管病基因、常见遗传代谢病基因占了很大比例，而近年才被认识的新致病基因基本没有。拿这一千多条记录去估计「临床相关基因的总体」，会系统性偏向老牌基因。

7.4 外部验证矩阵

LRG 的可信度不只来自自我声明，还能通过外部系统交叉验证。下表列出四条验证路径与各自的验证强度。

验证路径	具体做法	能验证什么	强度
三大基因组浏览器	在 Ensembl、NCBI、UCSC 中检索 LRG 编号	编号是否被主流系统接纳	强
HGVS 校验工具	用 Mutalyzer、VariantValidator 校验写法	语法与坐标是否自洽	强
与 RefSeqGene 逐位比对	下载同一位点的 NG_ 序列与 LRG 序列比对	序列是否真的同源	强
与 MANE 交叉核对	比对 MANE Select 标记与 LRG 固定转录本	转录本选择是否与共识一致	中

7.5 它为何能持续：因为稳定性本身就是需求，而需求没有保质期

一个 2021 年停更的资源，为什么到 2026 年还值得单独写一篇？

因为它解决的那类需求没有保质期。临床记录的保存期以几十年计，患者的随访是终身，历史报告的复核请求会在任何一年出现。只要还有人在查十年前的报告，那批冻结的记录就还有用。这与研究数据集恰好相反：研究数据集的价值往往随新数据出现而衰减，而坐标锚点的价值随时间推移反而上升，因为漂移累积得越多，越需要锚点。§4.4 的案例能成立，靠的正是这一条。

官方对这件事的态度写在 FAQ 里：若已无法用现有 LRG 描述某个序列变异，可能需要另建一条编号完全不同的新 LRG，但原 LRG 不会被「退役」，用该记录描述变异仍然有效。这句话是整个资源生存逻辑的正式表述——旧号永不废除，因为它服务的是历史，而历史不会过期。

它的可持续还有一层技术与成本上的原因：固定段冻结不动，可更新段全自动刷新，人工只需处理极少的替代事件。一个几乎不需要人力的系统，天然容易长期存活。这也解释了为什么它停更数年之后，站点仍能访问、数据仍能下载、清单仍能被脚本解析。

§8 生态位与历史

8.1 从 RefSeqGene 到 LRG：一条解决「版本混乱」的路线

要理解 LRG 的设计，得先看它接过的是什么棒。2000 年代中后期，NCBI 启动了 RefSeqGene 计划，为临床重要的基因位点提供基因组参考序列，登录号以 NG_ 开头。这一步解决的是「基因组层面的参考序列该用哪一条」，但没解决版本问题——NG_ 编号同样带版本，修订同样会进位。

LRG 在 2010 年前后提出，2010 年《Genome Medicine》那篇方法学文章是它的正式亮相。文章把当时的问题描述得很具体：随着基因结构复杂度认识的加深、基因表达细节理解的推进，准确描述致病变异变得越来越困难，部分原因是当时的参考 DNA 序列格式不能完全满足需求。文章给出的方案是「单文件记录 + 唯一稳定的参考 DNA 序列 + 全部相关转录本与蛋白」，并明确说这个格式建立在此前相当成功的 RefSeqGene 计划之上。

2014 年《Nucleic Acids Research》的介绍文章进一步说明了规模与目标。文中写道：目前已有七百余条 LRG 建成，其中四百余条公开可用；目标是「为每个有临床意义的位点建一条 LRG」。回头看，这个目标最终没有实现——停在了一千三百余条，而不是两万条。

8.2 2008 到 2021：十三年建了一千三百条

把时间线摊开看，能更清楚地理解这个资源为什么停得如此平静。

时间	事件	依据
2008 年前后	项目启动，作为 RefSeqGene 之上的一层稳定化设计	官方与两篇论文交代的背景
2010 年	方法学文章发表于 Genome Medicine	文献可查
2014 年	介绍文章发表于 Nucleic Acids Research，称七百余条已建、四百余条公开	论文摘要原文
2014 年 12 月	XML schema 1.8 存档	FTP 目录时间戳
2019 年 8 月	XML schema 1.10 加入 MANE 标记与替代指向字段	官方新闻页
2021 年 3 月 31 日	第 810 版发布，一千三百余条记录，零条待定	发布说明原文
2021 年 3 月 31 日	网站最后更新，此后不再新增记录	官方逐页横幅

从 2014 年的七百余条到 2021 年的一千三百余条，七年新增六百条左右，平均每年不到一百条。这个速度本身就预示了结局：人工逐条审校的产能，注定追不上基因组注释扩张的速度。

8.3 MANE 的诞生与接力

2019 年 8 月的 schema 1.10 是一次转折点的技术预兆。这次升级加了两样东西：MANE 来源标记，以及 superceded_by 字段。前者说明 MANE 已经成为记录里需要标注的信息，后者说明官方已经预料到记录会被替代。

MANE 是 NCBI 与 EMBL-EBI 的联合项目，目标是发布一套全基因组范围的转录本集合，每个蛋白编码位点选一条证据最充分的转录本，且该转录本在 RefSeq 与 Ensembl 之间逐碱基一致。这是一个比 LRG 更激进的方案——LRG 只要求同一条记录内部稳定，MANE 要求两个联盟之间一致。

官方 FAQ 提到，当时 MANE Select 已在约三分之二的蛋白编码位点上定义完成。这个比例还在上升。对临床报告而言，MANE 提供的东西更实用：它告诉报告者该用哪条转录本，且这条转录本在两个主流体系里是同一个。

于是接力关系就很清楚了。LRG 解决「序列会变」，MANE 解决「两个联盟不一致」。前者需要大量人工，后者可以规模化。当一个方案能同时解决两个问题且成本更低时，前者的退场几乎是必然。

§9 使用指引

9.1 三种角色的路径

同一个资源，不同角色要的东西不同，最短路径也不一样。

角色	主要诉求	最短路径	耗时量级
报单人（实验室签发人）	一行报告写对且长期可查	查清单确认有 LRG，读交叉引用表确认 t 与 p 的对应，双写 LRG 与 RefSeq	单基因十余分钟
数据工程师	批量接入、稳定主键	下载清单与交叉引用表入数据库，按基因符号与 RefSeq 编号建双索引	一次性半天
知识库维护者	历史记录可追溯	保留历史 LRG 键，新增记录改用 MANE，建替代关系表	按存量规模

三种角色的共同前置动作是同一个：先查清单。没查清单就开始设计，往往会在「你以为有、其实没有」的基因上白走一遍流程。

9.2 一条最短的可用流程

下面这条流程从零开始，把一个基因的 LRG 编号查出来、校验一次、写成报告行。全部命令可执行。

#-- 第一步：确认目标基因是否有 LRG
curl -sS --max-time 60 \
  "https://ftp.ebi.ac.uk/pub/databases/lrgex/list_LRGs_GRCh38.txt" \
  -o lrg_list.txt
awk -F'\t' '$2=="TP53" && $0 !~ /^#/ {print $1, $2, $3, $4, $5, $6, $7}' lrg_list.txt

#-- 第二步：取该记录的转录本与 RefSeq 对照
curl -sS --max-time 60 \
  "https://ftp.ebi.ac.uk/pub/databases/lrgex/list_LRGs_transcripts_xrefs.txt" \
  -o lrg_xref.txt
awk -F'\t' '$1=="LRG_321" && $0 !~ /^#/ {print $4, $5, $6}' lrg_xref.txt

#-- 第三步：用校验工具确认写法成立
curl -sS --max-time 30 \
  "https://rest.variantvalidator.org/VariantValidator/variantvalidator/GRCh38/LRG_321t1%3Ac.743G%3EA/all" \
  -o check.json
python3 -c "import json;d=json.load(open('check.json'));print([k for k in d][:6])"

三步跑完后，手上就有了三样东西：基因对应的 LRG 编号、该编号下每条转录本与 RefSeq 的对照、以及目标写法是否能被工具解析的结论。三样齐了，报告行就可以落笔。

9.3 引用方式

引用 LRG 有两个层面，要分开处理。

数据引用层面，官方提供的正式出处是 2014 年那篇介绍文章。引用时应写明记录编号与访问日期，因为记录本身不带版本号，访问日期是唯一能说明「你看到的是哪一版可更新段」的信息。这一点与带版本号的资源正好相反：那边版本号说明内容，这边访问日期说明内容。

报告引用层面，写法要遵守 HGVS 规范。基因组层面用 LRG_编号:g.，转录本层面用 LRG_编号t几:c.，蛋白层面用 LRG_编号p几:p.。前缀与编号之间不加空格，冒号紧接编号。

引用场景	写法要点	示例
学术引用	文章 + 记录编号 + 访问日期	调用 2014 年 NAR 文章，注明 LRG_321 与访问日
报告基因组行	LRG_编号:g.	LRG_321:g.7676607G>A
报告转录本行	LRG_编号t几:c.	LRG_321t1:c.743G>A
报告蛋白行	LRG_编号p几:p.	LRG_321p1:p.Arg248Gln
双写行	LRG 在前，RefSeq 在后	LRG_321t1:c.743G>A（NM_000546.5:c.743G>A）
数据库字段	单列存 LRG，单列存 RefSeq	两键并存，便于双向检索

§10 AI 使用声明

项目	声明
写作方式	由 AI 辅助撰写初稿，结构与事实点人工设定，全部数字回到官方清单与发布说明核对
研究材料	官方站点首页、关于页、FAQ 页、新闻页，FTP 目录与 2021 年最后一版发布说明，Europe PMC 收录的 2010 年与 2014 年两篇文章摘要
未使用材料	未使用任何患者数据、未使用机构内部数据、未使用付费数据库导出
数字来源	规模类数字取自官方清单与发布说明，未自行推算未公开的内部指标
推断标注	凡属推论而非官方表述者，正文已写明「按设计推断」或「官方未说明」
时效声明	记录集合冻结于 2021 年 3 月 31 日，本文核验日期见页脚，官网当前状态应以访问时为准
已知不确定处	编号空号的具体成因、可更新段 2021 年后是否仍在刷新，均未获官方明确说明
使用限制	本文不构成临床决策依据；具体位点是否适用 LRG 须逐条查官方清单

常见误读（避坑清单）

常见说法	实际	证据
LRG 就是另一个 RefSeq，只是名字不同	两套并行的编号体系，RefSeq 带版本、可修订，LRG 不带版本、永不修订	官方 FAQ 明写 LRG 无版本，序列永不改动；RefSeq 按 INSDC 惯例进位版本
LRG 现在还在新增记录	2021 年 3 月 31 日后不再新增	官网每页顶部横幅与 810 版发布说明
LRG 覆盖全部临床相关基因	只覆盖一千三百余个位点，且需社群主动申请建库	清单行数；FAQ 说明建库由请求发起
用了 LRG 编号就必须放弃 RefSeq 编号	两者并行，双写是常规做法	记录可更新段内自带与 RefSeq、Ensembl 的对照
LRG 里能查到变异与致病性	记录里没有任何变异、频率或表型数据	记录仅含序列、转录本、蛋白与注释
t1 一定对应 p1	不保证，多数记录碰巧一致，错位时按序号推必错	交叉引用表里同一记录的 t 与 p 序号需逐行核对
LRG 编号连号，可以按数字推记录数	存在一百余个空号，最大编号远大于记录数	清单最大编号 LRG_1431 与记录数差额
LRG 外显子编号等于临床惯用编号	LRG 另设连续编号，惯用编号存于可更新段作参照	FAQ 关于外显子编号体系的说明
记录被替代后旧号作废	旧号永不撤销，仍然可以用来描述变异	FAQ 明写原 LRG 不会被退役
LRG 的编号稳定，所以坐标也永远不变	编号稳，c. 坐标稳，但基因组坐标随装配体映射走，且映射表只到 2021 年	每条记录同时保存 GRCh37 与 GRCh38 两套映射，说明坐标本身与装配体版本相关
LRG 有正式 API 可以调	无 API，数据在 FTP 目录，站内搜索读前端索引	目录结构与站内脚本均可核实
停更说明它质量有问题	主动退场，替换为覆盖更广的 MANE	官网推荐 MANE 的措辞是优先，不是纠正

FAQ

Q1：LRG 现在还能用吗？

能用，但用法变了。已发布的记录其固定段永不改动，任何一条 LRG 写法今天依然可解析。变的是新增能力：2021 年 3 月 31 日之后不再有新的 LRG，所以只有当年建过库的位点可用。

Q2：为什么不继续建了？

官方没有发布正式的终止说明，只在站点上写了「不再生成新 LRG」，并推荐改用 MANE。从时间线看，人工逐条审校的产能追不上基因组注释的扩张速度，而 MANE 能以更低成本覆盖更广范围，这是最合理的解释。

Q3：LRG 与 RefSeqGene 是什么关系？

LRG 的基因组序列直接取自对应基因的 RefSeqGene 序列。一条 LRG 建立后，该基因的 RefSeqGene 会被冻结以保持一致。可以理解为 LRG 是 RefSeqGene 的一个快照，加上了单文件封装、无版本编号与专属外显子编号。

Q4：一条记录里为什么会有多条转录本？

因为有些位点的不同转录本各自承担不同的临床议题，只用一条会让某些变异无法无歧义描述。官方目标是每个位点一条，但必要时会放多条，TP53 就放了八条。

Q5：报告的蛋白写法能不能从转录本序号推出来？

不能。转录本序号与蛋白序号是两套独立的编号，不保证同号，遇到序号错位或只对部分转录本建了蛋白的记录，按序号推必错。写蛋白行必须查官方蛋白清单或交叉引用表逐条确认后再落笔。

Q6：LRG 编号在不同装配体之间会变吗？

编号不变，坐标会变。同一条记录在 GRCh37 与 GRCh38 上各有一套坐标，记录里两套并存。换算时要明确自己用的是哪一套，不能把一套坐标套到另一套上。

Q7：如果记录被新记录替代了，旧记录还能引用吗？

能。官方明确旧记录不会被撤销，仍可用于描述变异。区别只在于新旧记录哪个是当前的推荐，这一点看记录里的替代指向字段判断，不看编号大小。

Q8：我可以用 LRG 序列做比对或建索引吗？

可以，序列与注释可自由下载与再分发，按 EMBL-EBI 的使用条款引用即可。要注意的是序列库里应注明这是冻结版本，避免与其他来源的同一位点序列混用而不知差异。

Q9：LRG 里为什么有的记录没有 Ensembl 编号？

两联盟的注释体系在部分位点上没有完全收敛，交叉引用表里用短横线表示无对应。这不是数据缺失，而是确实没建立对应关系。做跨联盟换算时要单独处理这部分记录。

Q10：新项目应该用 LRG 还是 MANE？

默认用 MANE。只有当你要把结果写入长期档案、且该位点有 LRG 时，再加一个 LRG 编号作为稳定锚点。两个不用二选一。

Q11：LRG 的 XML schema 现在到哪个版本了？

目录里能看到 1.7、1.8、1.9 三个存档版本，当前版本号记录在 current_schema_version.txt 里，指向 1.10。1.10 引入了 MANE 标记与替代指向字段。

Q12：为什么站内搜索抓不到结果？

站内搜索靠前端脚本读取静态索引文件，直接抓 HTML 只能拿到空壳。要程序化检索，请直接下载索引 JSON 或清单 TSV，不要依赖页面渲染。

术语表

术语	含义
LRG	Locus Reference Genomic，位点参考基因组，本项目名
固定段	记录中永不改动的部分，含基因组序列、最少转录本与蛋白
可更新段	记录中定期刷新的部分，含映射、注释与旧编号
LRG 专属外显子编号	以固定段转录本为准的连续编号体系
RefSeqGene	NCBI 的基因位点基因组参考序列计划，登录号以 NG_ 开头
RefSeq	NCBI 的参考序列集合，登录号带版本
Ensembl	EMBL-EBI 的基因组注释体系，转录本登录号以 ENST 开头
GENCODE	Ensembl 的基因注释参考集
MANE	NCBI 与 EMBL-EBI 的转录本共识计划，含 MANE Select 与 MANE Plus
MANE Select	每个蛋白编码位点选定的单条共识转录本
HGVS	人类基因组变异学会，其命名规范是临床变异描述的行业标准
版本号	登录号最后一个点之后的部分，修订一次进位一次
转录本后缀 t	LRG 记录内转录本的序号，如 t1、t2
蛋白后缀 p	LRG 记录内蛋白的序号，如 p1、p2
待定记录	尚未定稿、仍可变更的记录，状态为 pending
已撤下记录	被撤下的记录，存于 suppressed 目录
替代指向	记录被新记录替代时的指向字段
装配体	参考基因组的一个版本，如 GRCh37、GRCh38
映射	记录序列与某个装配体坐标之间的对应关系
CCDS	共识编码序列集，多个数据库共同认可的编码区
位点特异性数据库	由社群维护的单一基因或疾病变异数据库
策展人	手工审校并录入记录的专业人员
基因组参考联盟	负责维护参考基因组的国际协作组织
HGNC	人类基因命名委员会，基因符号的权威来源
变异校验工具	检查 HGVS 写法语法与坐标是否自洽的软件
小型数字抑制	统计结果导出前对过小计数所做的保护性处理
位点	基因组上一个具体位置或区域，常指一个基因
等位基因频率	某等位基因在人群中的出现比例

附录 A：核心数字核对表

项	值	来源	来源层级
公开记录总数	1,325	第 810 版发布说明与 GRCh38 清单	官方发布说明
待定记录数	0	第 810 版发布说明	官方发布说明
最大编号	LRG_1431	GRCh38 清单	官方清单
编号空号数	106	最大编号减记录总数	本文推算
固定段转录本总数	1,641	转录本清单行数	官方清单
固定段蛋白总数	1,616	蛋白清单行数	官方清单
单条记录最多转录本	15 条	转录本清单聚合	官方清单
仅含一条转录本的记录	一千余条	转录本清单聚合	官方清单
已进入 Ensembl 的 LRG	862 条	lrgs_in_ensembl 清单	官方清单
区间长度中位数	约四十千碱基	GRCh38 清单计算	本文推算
最长区间	约两千二百千碱基	GRCh38 清单计算	本文推算
无 Ensembl 对应的转录本行	181 行	交叉引用表统计	官方清单
记录内转录本多于一条的基因	234 条	交叉引用表统计	官方清单
当前 XML schema 版本	1.10	版本号文件与新闻页	官方页面
最后发布日	2021-03-31	发布说明与网站横幅	官方页面
2014 年时已建记录	七百余条	2014 年 NAR 文章摘要	论文摘要
2014 年时公开记录	四百余条	2014 年 NAR 文章摘要	论文摘要
MANE Select 覆盖比例（2019 年）	约三分之二	官方新闻页与 FAQ	官方页面

附录 B：数字的来源分层

第一层：官方页面与官方文件。 记录总数、待定数、最大编号、转录本与蛋白条数、Ensembl 清单条数、schema 版本、最后发布日、停更声明、MANE 覆盖比例，均直接取自官方发布说明、清单文件与站内页面。这一层的数字可以用清单文件逐行复算，可信度最高。

第二层：论文摘要。 2014 年时「七百余条已建、四百余条公开」来自该年《Nucleic Acids Research》文章的摘要原文。这一层是历史快照，不能用来描述当前状态，只用于讲清增长节奏。

第三层：本文推算。 编号空号数、区间长度中位数与最大值、无 Ensembl 对应的行数、多转录本基因数，都是对官方清单做简单聚合得到的。聚合口径已在正文写明，数值可复现，但正式引用时应注明是本文计算而非官方公布。

未核实项。 编号空号的具体成因、可更新段在 2021 年之后是否仍在刷新、停更的完整决策过程，官方均未公开说明。正文中涉及这三处的地方已写明「官方未说明」或「按设计推断」。

附录 C：完整参考文献

编号	出处	用途
C1	MacArthur JA, Morales J, Tully RE, 等. Locus Reference Genomic: reference sequences for the reporting of clinically relevant sequence variants. Nucleic Acids Research, 2014. DOI: 10.1093/nar/gkt1198	2014 年规模与设计说明
C2	Dalgleish R, Flicek P, Cunningham F, 等. Locus Reference Genomic sequences: an improved basis for describing human DNA variants. Genome Medicine, 2010, 2:24. DOI: 10.1186/gm145	项目动因与格式设计
C3	Morales J. Locus Reference Genomic (LRG) resource: webinar, 2015	项目定位的科普说明
C4	LRG 官方网站，https://www.lrg-sequence.org/	停更声明、MANE 推荐、FAQ、新闻
C5	LRG FTP 目录，https://ftp.ebi.ac.uk/pub/databases/lrgex/	清单、交叉引用、发布说明
C6	HGVS 命名规范，https://hgvs-nomenclature.org/	变异写法依据
C7	NCBI RefSeq，https://www.ncbi.nlm.nih.gov/refseq/	上游序列体系
C8	Ensembl，https://www.ensembl.org/	平行注释体系

附录 D：任务代码

下面这段代码把前面分散的三步合成一个脚本：查基因、取对照、算双写行。它可以直接运行，输出可以直接贴进报告草稿。

#-- 一次跑完：查基因、取转录本对照、生成双写报告行
import urllib.request

BASE = "https://ftp.ebi.ac.uk/pub/databases/lrgex/"
GENE = "TP53"
NM_TARGET = "NM_000546"


def fetch(name):
    return urllib.request.urlopen(BASE + name, timeout=60).read().decode("utf-8")


#-- 第一步：在清单里定位基因
lrg_id = None
for line in fetch("list_LRGs_GRCh38.txt").splitlines():
    if not line.strip() or line.startswith("#"):
        continue
    f = line.split("\t")
    if f[1] == GENE:
        lrg_id = f[0]
        print("命中", f[0], f[1], f[2], "chr" + f[3] + ":" + f[4] + "-" + f[5], "strand", f[6])
        break

if lrg_id is None:
    print(GENE, "没有对应的 LRG，请改用 MANE 或带版本的 RefSeq")
else:
    #-- 第二步：取该记录下每条转录本的 RefSeq 与 Ensembl 对照
    rows = []
    for line in fetch("list_LRGs_transcripts_xrefs.txt").splitlines():
        if not line.strip() or line.startswith("#"):
            continue
        f = line.split("\t")
        if f[0] == lrg_id:
            rows.append(f)
            print("转录本", lrg_id + f[3], "RefSeq", f[4], "Ensembl", f[5], "CCDS", f[6])

    #-- 第三步：生成双写写法（以 c. 层面为例）
    for f in rows:
        if f[4].split(".")[0] == NM_TARGET:
            print("双写写法 LRG:", lrg_id + f[3] + ":c.位置REF>ALT",
                  "RefSeq:", f[4] + ":c.位置REF>ALT")

脚本里的坐标位置留作占位，需要按实际变异填写。输出会先给出基因对应的 LRG 编号与坐标，再列出全部转录本对照，最后给出双写模板。

附录 E：如果只记五件事

第一件：它停更了。 2021 年 3 月 31 日之后不再新增记录，官网现推荐有 MANE Select 的基因改用 MANE。这是打开任何讨论前必须先知道的一条。

第二件：它的核心卖点是不带版本号。 LRG_321 没有 .5 和 .6，固定段永不改动。这是它相对 RefSeq 唯一的、也是最彻底的差异。

第三件：t 与 p 序号不保证对应。 多数记录碰巧一致，所以直觉容易成立；一旦错位，按序号推就必错。写蛋白行必须查表。

第四件：它只有一千三百余个位点。 别指望它覆盖你的基因。第一动作永远是查清单，不是查文档。

第五件：它作为历史锚点长期有效。 旧号永不撤销，用旧记录描述变异永远成立。这一条决定了它停更之后仍然值得了解。