信息速览
FooDB 的全称是 The Food Database，一个把「食物里有什么」写成可检索表格的库。它不问某种食物有多少热量、多少蛋白质，而问这颗大蒜里到底出现了哪些化学物质、其中多少种已经知道含量。这个问题在各国官方的营养成分表里通常只有几十到一百多个答案，FooDB 给出的答案则数以千计。
它由加拿大阿尔伯塔大学的 David Wishart 实验室维护，与人体代谢组数据库 HMDB、药物数据库 DrugBank 出自同一团队。三者的分工可以用一句话概括：HMDB 管人体里的小分子，DrugBank 管药物，FooDB 管吃进去的东西。同一套编号习惯、同一套字段设计、同一批交叉链接，只是对象换成了餐桌。
因此它更像一部「食物化学成分的索引」，而不是一份测量报告。库里绝大多数化合物只被记录了「存在」，没有被记录「多少」；浓度一栏的数字来自数百家来源的汇编，彼此口径并不统一。理解这一点，比记住任何一个总数都重要。一屏速览见下表。
| 维度 | 内容 |
|---|---|
| 全称 | The Food Database（FooDB） |
| 维护方 | 阿尔伯塔大学 Wishart 实验室 / 加拿大代谢组学创新中心（TMIC） |
| 站点版本 | Version 1.0；下载页标注 Pre-release 1.0 |
| 数据截止 | 2020 年 4 月 7 日 |
| 组织方式 | 食物、化合物、浓度三张主表，另加营养素分组表 |
| 标识符 | 食物五位编号，化合物六位编号 |
| 食物记录 | 近千条（Food 表） |
| 化合物记录 | 数万条（Compound 表，详见 §2.4） |
| 浓度记录 | 五百余万条（Content 表） |
| 来源数 | 三百余家，其中带定量数据的四家 |
| 浓度单位 | 每 100 克食物中的毫克数 |
| 字段规模 | 每个化合物记录一百余个字段 |
| 许可 | CC BY-NC 4.0，非商业自由，商业需授权 |
| 下载 | 免注册、免登录，整包下载 |
| 已知短板 | 八成以上化合物未定量，单位与命名未归一 |
§1 它要解决的具体麻烦
1.1 营养成分表只回答了一百多个问题
任何做过膳食调查的人都会碰到同一堵墙。你手上有一份二十四小时回顾，能算出受试者吃了多少克西兰花、多少克咖啡，也能从食物成分表里查到热量、蛋白质、脂肪、几种维生素和矿物质。然后你想再往前一步，问一句「他今天摄入的槲皮素大概多少」，表里没有这一栏。
这不是哪个国家偷懒。官方的食物成分表是为公共卫生与标签法规服务的，它必须保证每个数字都来自可复现的标准方法，因此只收录那些有标准方法、有标准品、有实验室能常规测的项目。这套约束把字段数锁在一两百个的量级，而食物中已知的化学物质数量是数万级。
FooDB 的出发点就是把计数单位从「营养素」换成「化合物」。它不再问「这份食物符不符合标签规范」，而问「文献里报道过这份食物里出现过哪些分子」。这个转向让字段数从一百多跃升到数千，同时也把可靠性从「标准方法」降到了「文献报道」。库的全部优点与全部麻烦，都从这一次转向里来。
一个常被引用的对照：美国农业部的库把生蒜拆成六十七项，FooDB 把同一颗蒜拆成两千三百零六项。数量的差距不是精度提升，而是口径扩张——后者的绝大多数项只是「检出过」，没有含量。
1.2 三条常见的错误期待
| 常见期待 | 实际情况 |
|---|---|
| 以为库里的浓度都是实验室测出来的 | 浓度是数百家来源的汇编，真正带定量数据的只有四家成分库，其余多为只记「含有」的文献 |
| 以为它像营养成分表一样做过标准化 | 同一化合物有多个名称、同一食物有多个叫法、单位混用 ppm 与毫克每百克，表内未归一 |
| 以为化合物记录的条数就等于被搞清楚的物质种数 | 其中五万余条是推定存在而非分离鉴定，另有四万余条属脂类，有浓度值的只有万余种 |
1.3 它能给到的与给不到的
| 你的需求 | 它给的 | 够不够 |
|---|---|---|
| 某种食物里报道过哪些化合物 | 按食物查化合物，一次列出数千条，带结构与分类 | 够，这是它的主场 |
| 某种化合物出现在哪些食物里 | 按化合物查食物，可作暴露来源的初筛 | 够，但需自行去重与对齐名称 |
| 某食物某化合物的含量 | 一个平均值，附若干条来源与数值 | 勉强够做量级判断，不够做定量结论 |
| 同一化合物在不同食物间的比较 | 可以并列，但单位需先统一 | 够，前提是先做换算与异常值剔除 |
| 浓度测定的不确定度、样本量、检测方法 | 不提供，只给来源名称与数值 | 不够 |
| 加工食品的配方级组成 | 不提供，只有粗粒度品类 | 不够 |
| 可食部位与不可食部位的区分 | 不标注，数据里混有种子、果皮、茎叶 | 不够，需自行剔除 |
| 二〇二〇年之后的新数据 | 不提供，库已停止更新 | 不够 |
1.4 你的处境与它能帮到的事
| 你的处境 | 它能帮你什么 | 下一步该做什么 |
|---|---|---|
| 想为一份膳食问卷补上植物次生代谢物的摄入估算 | 给出食物到化合物的候选清单与量级 | 先把食物名对齐到问卷编码，再逐化合物检查是否有浓度 |
| 想找某种风味物质可能来自哪些食材 | 按化合物反查食物，附带香气与滋味描述 | 用香气字段交叉验证，别把「检出」当作「主要贡献」 |
| 想为食物-化合物二部图做嵌入或推荐 | 现成的边表，节点带结构标识与分类 | 剔除无浓度的边，按来源分层加权 |
| 想找某个化合物的食品基质背景 | 列出所有报道过它的食物 | 注意同物异名，先按结构标识去重 |
| 想做食品安全的毒理筛查 | 可作候选化合物清单 | 库内无毒理终点，需外接其他库 |
1.5 一句话判断
如果你要的是「某种食物里可能出现哪些分子」的宽口径索引，FooDB 是目前覆盖最广的公开选择；如果你要的是「这份食物里某物质到底有多少」的可引用数字，它的诚实程度只到「某文献报道过某个值」这一层。
1.6 不适合谁：四条边界
第一，不适合做法规与标签的人。标签需要可复现的标准方法学、需要检测限与不确定度，FooDB 两样都没有。它给的是一堆来源不明的数字的平均值，无法支撑任何合规声称。
第二，不适合做精确暴露评估的人。暴露评估的误差预算要求每个浓度值带样本量与方法信息，FooDB 只给来源名称。用它算出的摄入量，误差主要来自浓度而非食物消费量，且这个误差无法量化。
第三，不适合做配方研发的人。库里没有配料表、没有配比、没有工艺，也没有品牌与批次。想回答「这款饮料含多少某香精」，只能回到供应商的规格书。
第四，不适合需要最新数据的人。数据只到二〇二〇年，此后高分辨质谱普及带来的大量新检出没有进来。做近五年的食品趋势分析，它只能当历史基线。
§2 数据构成与规格
2.1 四张主表，而不是五个模块
坊间常把 FooDB 描述成「食物、化合物、浓度、风味、通路」五个模块。这个说法在概念上不算错，但与下载到的表结构对不上。整包下载解压后是四张主表：Compound、Food、Content、Nutrient，另有若干引用与交叉链接表。
风味不是独立模块。颜色、香气、滋味是 Compound 记录里的字段，一个化合物可以标「大蒜气味」「苦味」「无色」，这些描述跟着化合物走，不构成单独的实体表。想按风味检索，正确做法是筛化合物字段，而不是找一张风味表。
通路也不是独立模块。站点上化合物的通路信息以外链形式指向 SMPDB（同团队的小分子通路图库），FooDB 自身不存通路拓扑。因此「五个模块」应当理解为「四张表加两类外链」。
| 表 | 一行是什么 | 规模（下载页口径） |
|---|---|---|
| Food | 一种食物，带五位编号与名称 | 不足千行 |
| Compound | 一种化合物，带六位编号、结构、分类、风味字段 | 数万行，见 §2.4 |
| Content | 一条浓度观测：某食物中某化合物的某个值 | 五百余万行 |
| Nutrient | 一个营养素分组（蛋白质、脂肪、某类脂肪酸等） | 数十行 |
四张表的关系是典型的星型：Content 是事实表，Food 与 Compound 是维度表，Nutrient 是把化合物按营养学口径分组的另一套维度。这个设计的好处是浓度记录可以无限追加而不动字典；坏处是任何一次分析都要先做两次连接。
2.2 字段字典
Compound 表字段最多，官方称每个化合物记录有一百余个字段。实际分析常用的是下面这些。
| 字段 | 含义 | 可用性 |
|---|---|---|
id |
六位化合物编号 | 主键，稳定 |
name |
化合物名称 | 常用，但同物异名严重 |
cas_number |
CAS 登记号 | 部分缺失 |
smiles / inchi / inchikey |
结构标识 | 覆盖较好，去重首选 |
formula / mass |
分子式与分子量 | 覆盖较好 |
kingdom / superclass / class / subclass |
化学分类四级 | 有缺失，曾被第三方用 ClassyFire 重算 |
food_source |
报道过的食物 | 冗余字段，与 Content 不一致 |
flavour / aroma / taste |
风味描述 | 文本，未结构化 |
biosource / biological |
生物来源与生理作用 | 文本，稀疏 |
Content 表的字段少而关键，全部围绕「一个数值从哪来」。
| 字段 | 含义 | 备注 |
|---|---|---|
food_id |
指向 Food 的五位编号 | 有缺失，部分记录只有食物名 |
orig_food_common_name |
食物名称原文 | 缺失时只能靠它对齐 |
compound_id |
指向 Compound 的六位编号 | 有缺失 |
orig_source_name |
化合物名称原文 | 与字典表名称常不一致 |
orig_content |
浓度数值 | 主体载荷 |
orig_unit |
原始单位 | 混杂，需统一 |
orig_min / orig_max |
来源给出的上下限 | 仅部分来源有 |
source_type |
来源类型 | 可据此分层 |
citation |
文献或库的引用 | 文本，未规范化 |
2.3 一条浓度记录的解剖
取一条典型的 Content 行，它读起来是这样的。
#-- 一条 Content 记录的各字段（示意，非真实记录）
food_id -> "1234"
orig_food_common_name-> "Garlic"
compound_id -> "000123"
orig_source_name -> "Quercetin"
orig_content -> 1.7
orig_unit -> "mg/100 g"
source_type -> "DUKE"
citation -> "Duke's Phytochemical and Ethnobotanical Databases"
这条记录回答的只有一件事：有人报道过大蒜里槲皮素的含量是每百克一点七毫克。它不回答测了几份样品、用的什么方法、检出限多少、是不是同一个品种。这些信息在原始文献里，但不在表里。
于是同一个「大蒜—槲皮素」组合在 Content 表里会出现多行，来自不同文献、不同成分库、不同年份，数值可能是一点七，也可能是十七。站点在展示层给出一个平均值，而在下载表里保留全部行。这个设计是有意的：它把「选哪个值」的决定权交给了使用者，代价是使用者必须自己承担这个决定。
2.4 三套并行口径
同一个库，三篇文章会给出三个不同的化合物总数，原因在于数的是不同的层。
第一层是字典层。Compound 表的行数是七万零四百七十七行（第三方对二〇二〇年四月版下载包的统计），这是「化合物记录」数，不等于「被确认存在的化合物」数。研究者指出其中五万余条是推定存在，四万余条属脂类或类脂物质，真正由实验分离鉴定的只是一部分。
第二层是有浓度层。Content 表里出现过的不同化合物约一万零九百种（第三方清洗统计），这是「至少有一条浓度记录」的化合物数。再严格一点，只保留名称与数值都齐全的记录，可用的化合物降到两千六百三十三种。
第三层是食物层。Food 表的行数不足千，但 Content 表里出现过的不同食物名有九千余个。多数食物名从未被提升为独立的 Food 记录，只以字符串形式挂在浓度行上。
| 口径 | 数的是什么 | 量级 | 出处 |
|---|---|---|---|
| 字典层 | Compound 表行数 | 70,477 | 二〇二三年对下载包的统计 |
| 有浓度层 | Content 中出现过的不同化合物 | 一万余 | 第三方清洗后统计 |
| 严格可用层 | 名称与数值齐全的化合物 | 数千 | 营养流行病学清洗流程 |
| 食物层（表） | Food 表行数 | 近千 | 下载页 |
| 食物层（串） | Content 中不同食物名 | 九千余 | 第三方清洗后统计 |
看到任何一个「FooDB 有多少化合物」的说法，第一件事是问它数的是哪一层。三层之间差一个数量级，互相并不矛盾。
2.5 标识符与稳定性
食物用五位编号，化合物用六位编号，站点把这套编号当作永久标识来承诺：编号在站内可检索，在下载数据里也带着，同一个编号永远指向同一个实体。
实际使用中，编号的覆盖并不完整。Content 表里有相当比例的记录只有名称、没有编号，尤其是来自文献转录的部分。这意味着「按编号连接」会丢掉一批记录，「按名称连接」又会引入同物异名的错误。稳妥的做法是两条路都走一遍，再按结构标识（InChIKey）做终局去重。
2.6 浓度与单位
站点的规范单位是每 100 克食物中的毫克数。原始来源五花八门：有的用 ppm，有的用每百克微克，有的用微摩尔，有的干脆只给「微量」「主要成分」这类定性描述。入库时做了折算，折算规则没有公开文档。
三个后果值得记住。
其一，只给上下限的来源被取了中值。DUKE 植物化学库只记录测定的最低量与最高量，不记录单体值，FooDB 取两者平均后写入。这等于把「区间」压成了「点」，而且这个点往往偏高，因为最高值常来自极端样本。
其二，零值被保留。浓度为零的记录不删，因为它可能表示「检出限以下」，也可能表示「确实没有」。两种含义混在一起，直接做统计会把「未检出」当成「含量为零」。
其三，单位事故有实例可查。有研究报告了蓝莓维生素 K 在库中记为每百克三十毫克，而标准成分表是每百克零点零二毫克，源头是 DUKE 以 ppm 记录后被放大了百倍。这类错误不是孤例，硒与烟酸也有类似偏高。
2.7 风味与通路挂在哪里
想把 FooDB 当风味数据库用的人，需要先知道它的边界。香气与滋味是化合物属性，一个化合物可以同时标「存在于大蒜」「有硫味」「有刺激性气味」。这些字段是自由文本，没有受控词表，也没有强度分级，因此只能做粗筛，不能做风味强度建模。
通路信息则完全在库外。化合物页会给出 SMPDB 的链接，指向该化合物参与的小分子反应图。FooDB 自身不存反应、不存酶、不存通路拓扑。想研究「蒜氨酸在体内变成什么」，路径是 FooDB 找化合物，再去 HMDB 或 SMPDB 看代谢。
§3 它的身份：谁的库，对谁负责
3.1 三个名称，一个东西
站点标题写 FooDB，副标题写 The Food Database，正文里又常出现全大写的 FOODB。三个写法指同一个库。文件名与下载包里用的是 foodb，学术引用里通常写 FooDB。
版本标识有一处不一致值得记下：首页写 Version 1.0，下载页写 Pre-release 1.0。前者读起来像正式版，后者说明维护方自己把它当作尚未定稿的预发布。此后近六年再无版本更新，这个「预发布」状态事实上被冻结了。
3.2 Wishart 套件里的食物分支
David Wishart 在阿尔伯塔大学建立的这一组库，习惯上被称作「小分子知识库家族」。它们共享同一套设计哲学：一个实体一个页面，页面上一百余个字段，字段按「命名—结构—理化—生物学—来源—浓度」的顺序排列，末尾挂交叉链接。
| 库 | 管什么 | 计数单位 | 与 FooDB 的关系 |
|---|---|---|---|
| HMDB | 人体内源代谢物 | 代谢物 | 同一化合物在两库各有页面，互相链接 |
| DrugBank | 药物与药物靶点 | 药物 | 食物-药物相互作用不在 FooDB，需另找 |
| T3DB | 环境毒物与毒素 | 毒物 | 食物中的天然毒素部分重叠 |
| SMPDB | 小分子通路图 | 通路 | FooDB 的通路信息以外链指向它 |
| FooDB | 食物中的化学成分 | 食物×化合物 | 本词条主体 |
| MCDB | 乳汁成分 | 化合物 | 更细的单一基质版本 |
这张表解释了一个常见困惑：为什么在 FooDB 里查到的化合物，往往在 HMDB 里也有一模一样的页面布局。因为它们本就是同一套模板喂进不同的数据。对使用者来说，好处是学习成本只付一次；坏处是容易忘记三个库的可靠性完全不同——HMDB 有相当比例的实验测定，FooDB 的主体是文献汇编。
3.3 谁在维护，钱从哪来
站点署名的维护方是阿尔伯塔大学 Wishart 实验室，运营依托加拿大代谢组学创新中心（TMIC）。站内没有披露资助来源，也没有编委会名单，只有一封用于商业授权的联系邮箱。
这一点对使用有实际影响：当你在论文里写「据 FooDB」，审稿人无法通过公开文档判断这个库的策展标准、错误更正流程与撤稿机制。库的权威性建立在团队其他库的声誉上，而不是建立在这个库自己的方法学文档上。
3.4 对谁负责：三种责任边界
对引用者，它负责的是「可检索、可追溯到一个来源名称」。每条浓度记录都带来源字段，虽然这个字段常常只是一个库名而不是一篇文献。
对被聚合的源库，它负责的是「标注出处」。USDA、DTU、Phenol-Explorer、DUKE 的数据进入 FooDB 后仍带原名，这是它敢自称聚合库的底气。
对商业使用者，它负责的是「划清许可边界」。数据以 CC BY-NC 4.0 发布，非商业可自由使用；商业使用需要单独取得授权。这条边界在实务中经常被忽略，尤其是企业内部工具把小库并进产品时。
3.5 三根坐标轴
理解这个库的最快方式，是把它想成一个三维坐标系：一轴是食物，一轴是化合物，一轴是浓度。任何一个数据点都是三个坐标的乘积，缺一个就不成立。
绝大多数已有记录落在「食物×化合物」这个平面上，第三轴的坐标是空的。这就是为什么库看起来很大（平面上的点极多），用起来很小（有高度的点很少）。所有关于 FooDB 的误判，几乎都源于把这个平面当成了立体。
§4 它的手艺：聚合，而不是测量
4.1 食物成分天生测不全
一份食物里的化学物质数量，取决于你用什么方法去找。用靶向方法找三十种维生素与脂肪酸，得到三十个数字；用非靶向高分辨质谱找，一份样本可以打出数千个特征峰，其中能定性的只是少数。
这个不对称决定了任何「完整的食物成分库」都不可能靠单一实验室完成。以大蒜为例，文献报道过的化合物超过两千种，但其中被定量过的只有一百四十六种，其余两千多种只知道「存在」。这不是哪个库偷懒，而是定量一种化合物需要一个标准品、一条标准曲线、一次方法验证，成本远高于「检出」。
FooDB 的应对策略是承认这个现实，然后把「存在」与「含量」分开记录：所有化合物都进字典表，只有有数值的才进浓度表。这个设计是对的，问题出在后来的使用者常常只看字典表的行数。
4.2 数百家来源，三种类型
站点称全库聚合了数百家来源。第三方梳理把这些来源分成三类：科学文献、国家食物成分库、食物本体（对食物分类的概念框架）。
三类来源的性质差别很大。科学文献提供的是「某研究在某样本中检出某物质」，往往样本量小、基质特定、方法各异；国家成分库提供的是标准化的营养素数值，可靠但字段窄；食物本体提供的是分类与命名，不含数值。
关键事实是：把「必须有食物名、必须有化合物名、必须有浓度值」三条同时加上之后，全部来源里只剩四家能留下记录。其余数百家贡献的是「存在性」，不是「含量」。
| 来源 | 性质 | 擅长 | 在库中的角色 |
|---|---|---|---|
| USDA 国家营养成分库 | 国家成分库 | 维生素、矿物质、脂肪酸、氨基酸 | 食物记录最多的贡献者 |
| DTU Frida（丹麦） | 国家成分库 | 同上，北欧食物为主 | 补充欧洲食物 |
| Phenol-Explorer | 多酚专题库 | 多酚类，逐条溯源到原始文献 | 植物次生代谢物的主力 |
| DUKE 植物化学库 | 植物学汇编 | 植物化学物质覆盖广 | 覆盖最广，但只给上下限 |
| 其余数百家 | 文献与本体 | 存在性证据 | 只贡献「含有」 |
4.3 有定量数据的只有四家
这张表值得单独强调，因为它决定了数据质量的分布。
USDA 贡献了绝大多数食物记录，但它贡献的化合物只有一百余种，全是常规营养素。DTU 类似，化合物数一百余种。Phenol-Explorer 的化合物数近五百，全部是多酚，且每条含量都能追到原始文献，是四家里溯源质量最高的。DUKE 的化合物数最多，超过七千，但它只记录测定的最低值与最高值，且包含大量不可食用部位。
四家拼起来的覆盖是这样的：常规营养素靠 USDA 与 DTU，植物次生代谢物靠 Phenol-Explorer 与 DUKE。前两家可靠但不深，后两家深但可靠性参差。FooDB 把四家混在一张表里，没有在字段上标注「这一条来自哪一类」，只给来源名。这是使用时必须自己补的一层。
4.4 平均值的代价
同一食物同一化合物有多个来源时，站点展示平均值。这个选择在工程上简单，在统计上代价明确。
平均值抹掉了离散度。若某化合物在某食物中的报道值从每百克零点一毫克到十毫克，平均可能是一毫克，而真实的分布是双峰——不同品种、不同产地、不同部位各占一峰。使用者拿到一毫克，会以为这是一个有代表性的中心，实际上它可能不属于任何一个真实样本。
平均值也抹掉了来源质量。一条来自 Phenol-Explorer 的、可溯源到原始文献的值，和一条来自 DUKE 的、由上下限平均出来的值，在平均时权重相同。前者的不确定度可能是百分之十，后者可能是十倍。
4.5 案例：一颗蒜的两千三百零六与一百四十六
这个案例可以贯穿整个库的逻辑。
第一步，问「大蒜里有多少种化合物」。按字典层回答，两千三百零六种。这个数字让 FooDB 显得远比官方成分表强大——后者只列六十七项。
第二步，问「其中多少种知道含量」。按浓度层回答，一百四十六种。剩下两千一百六十种只有「存在」的记载。
第三步，问「这一百四十六种的含量可信吗」。答案取决于来源：若来自 Phenol-Explorer，可追到原始文献；若来自 DUKE，只是一个区间中点；若来自文献转录，可能连样本是哪个品种都不知道。
三步走完，同一个库给出的三个答案分别是两千三百零六、一百四十六、以及一个无法量化的可信度。任何一个只引用第一个数字的说法，都在无意中夸大这个库的能力。
4.6 为什么不做名称与单位归一
这是最常被抱怨的一点：为什么不把「维生素 B5」和「泛酸」合成一条，为什么不把 ppm 全换成毫克每百克。
部分原因是规模。数万条化合物、五百万条浓度记录，逐条人工归一是不现实的。部分原因是来源约束：改写源库的名称会破坏溯源，而溯源是这个库唯一的信誉来源。部分原因是这件事在库外更容易做——Phenol-Explorer 已经做过自己那部分的归一，使用者只需要在合并层做一次映射。
代价落在使用者身上。任何一次严肃的使用，都要先写一段名称映射与单位换算的代码，而这段代码的质量决定了结论的质量。已有研究把这段清洗流程完整发表出来，可以作为起点。
§5 取数：从网页点击到整包下载
5.1 四条路径的取舍
| 路径 | 适合谁 | 拿到什么 | 限制 |
|---|---|---|---|
| 网页按食物浏览 | 想快速看某食物含什么 | 化合物列表与浓度摘要 | 分页，无法批量 |
| 网页按化合物浏览 | 想找某物质的食物来源 | 食物列表与浓度 | 同上 |
| 整包下载 | 要做分析的人 | 四张表的全量数据 | 体量以 GB 计，需自行清洗 |
| 结构检索 | 手上有结构想知道是不是已知食物成分 | 结构匹配结果 | 只做结构层，不含浓度 |
四条路径的数据同源，差别只在聚合粒度。做任何需要统计的事，都应当走整包下载；网页只适合确认某个具体事实。
5.2 下载页给什么
下载页提供整包，格式包括 JSON、CSV、XML、SQL，另有质谱与核磁的交换格式（mzML、nmrML）用于谱图文件。站点的合规声明写明：访问与下载不需要身份验证，浏览器直接可取。
整包解压后是若干表文件，命名直观（compound、food、content、nutrient 及各交叉链接表）。体量最大的永远是 content，因为它是五百万行级别的事实表；compound 次之，因为每条记录一百余个字段；food 与 nutrient 都很小，可以直接在内存里当字典用。
5.3 用 pandas 读一张事实表
下面这段是最小可运行路径。它只做三件事：读表、选列、按来源分组看规模。
import pandas as pd
#-- 整包解压后的目录，按实际文件名调整
BASE = "foodb_2020_04_07_csv"
content = pd.read_csv(f"{BASE}/Content.csv", low_memory=False)
print(content.shape) #-- (行数, 列数)
#-- 只留分析必需的列，五百万行全字段读入会吃掉十几 GB
cols = ["food_id", "orig_food_common_name", "compound_id",
"orig_source_name", "orig_content", "orig_unit", "source_type"]
c = content[cols].copy()
#-- 看每个来源贡献了多少条浓度记录
print(c["source_type"].value_counts().head(10))
#-- 单位先看一眼再决定怎么换算，别默认全是 mg/100 g
print(c["orig_unit"].value_counts().head(15))
读进来之后第一件事不是统计，而是看单位分布。单位不统一时，任何按化合物求均值的操作都会得到无意义的数。
5.4 两条浏览轴
网页端提供两个视角：按食物看（FoodView，列出一种食物的所有化合物），按化合物看（ChemView，列出一种化合物的所有食物）。这两个视角是同一张事实表的两个投影，切换视角不改变数据。
实践中，FoodView 适合做「这份食材值不值得研究」的初判，ChemView 适合做「这个化合物从哪来」的溯源。前者看行数，后者看分布。
5.5 结构检索与谱图
站点提供结构检索，可以画一个子结构或贴一个 SMILES，返回库内匹配的化合物。这对天然产物研究很实用：手上分离到一个未知峰，先看它是不是已经在食物成分的名单里。
谱图层面的支持体现在格式上：质谱以 SPLASH 标识符寻址，核磁以 nmrML 存放。这意味着理论上可以把自测谱图与库内谱图做匹配，但库内谱图的覆盖面远小于化合物覆盖面，多数化合物没有谱图。
5.6 版本固定
库已停止更新，这让版本固定变得简单：引用时写清「Pre-release 1.0，数据截止二〇二〇年四月七日」，就足以定位到唯一一份数据。这与仍在滚动的库相反——那些库必须写下载日期，否则结果无法复现。
需要提醒的是，站点的网页层与下载包可能不同步。网页上的某些化合物页面在下载表里找不到对应行，反之亦然。做可复现分析应以下载包为准。
§6 与库内条目的关系
6.1 关系图谱
在「千方 hub」已收录的资源里，FooDB 的位置不是孤立的。它同时是阿尔伯塔家族的一员，又是食物成分数据这一支的代表。
| 库 | 与本库的关系 | 差异要点 |
|---|---|---|
| HMDB | 同门，管人体内源代谢物 | 对象从餐桌换到体液；实验测定比例更高 |
| DrugBank | 同门，管药物 | 对象是外源小分子药物，带靶点与相互作用 |
| USDA FoodData Central | 上游来源之一 | 以营养素为字段，食物记录数远大于 FooDB |
| Phenol-Explorer | 上游来源之一 | 只做多酚，但每条可溯源到原始文献 |
| LOTUS 天然产物库 | 曾考虑整合 FooDB，最终排除 | 排除理由是许可不允许再发布 |
最后一行值得展开。天然产物文献库 LOTUS 在构建时扫描了四十余个公开资源，FooDB 在候选名单里，最终没有进入整合。原因不是数据质量，而是许可：FooDB 的 CC BY-NC 条款要求商业使用另行授权，与「可自由再发布」的整合前提冲突。同一份数据，在一个场景里是开放资源，在另一个场景里就成了受限资源。这个例子说明许可证不是标签，而是会实际改变数据流向的约束。
6.2 与 HMDB 的分工：体液与餐桌
HMDB 收录的是人体内源代谢物，样本是血清、尿液、脑脊液；FooDB 收录的是食物成分，样本是食材。两者的交集在于「食物中的分子进入人体后仍是同一个分子」——槲皮素在大蒜里叫槲皮素，在血浆里也叫槲皮素。
这份交集让两个库可以接起来做一件事：从膳食摄入推到体内暴露。路径是先在 FooDB 找食物中的化合物，再到 HMDB 看该化合物的吸收、分布、代谢与排泄。站点之间的交叉链接正是为这条路径准备的。
分工之外还有一层质量差异需要记住。HMDB 有相当比例的数据来自该团队自己的实验测定与文献精读，一个代谢物页面上的浓度往往标注了体液类型、病理状态与样本量。FooDB 的浓度多数只是「某来源报道过某值」。同样是一百多个字段的页面，可信度不在一个层级。
6.3 与 DrugBank 的分工：吃进去的药与吃进去的饭
DrugBank 管的是药物，带靶点、带相互作用、带剂量。FooDB 管的是食物成分，不带靶点、不带相互作用、不带剂量。
两者唯一该被联系起来的地方是食物-药物相互作用，而这恰恰是 FooDB 不提供的。想研究「西柚汁为什么影响某些药物代谢」，需要的是呋喃香豆素对 CYP3A4 的抑制数据，这类数据在 DrugBank 的相互作用记载与药理学文献里，不在食物成分表里。FooDB 能做的是告诉你西柚里有呋喃香豆素，含量大概多少，仅此而已。
把这三个库放在一起看，能看出一条清晰的分界：HMDB 回答「体内有什么」，DrugBank 回答「药物做什么」，FooDB 回答「吃的东西里有什么」。三个问题都很重要，但没有一个能替代另外两个。
6.4 与 USDA FoodData Central 的区隔
这是最容易混淆的一对，因为 FooDB 的多数食物记录正是从 USDA 来的。
| 维度 | FooDB | FoodData Central |
|---|---|---|
| 计数单位 | 化合物 | 营养素 |
| 字段宽度 | 每个化合物一百余字段 | 每个食物数十到数百营养素 |
| 食物粒度 | 不足千条（表内） | 数十万条，含品牌产品 |
| 数值来源 | 数百家汇编 | 官方实验室分析与厂商提交 |
| 品牌与加工食品 | 基本没有 | 大量覆盖 |
| 更新 | 停在二〇二〇年 | 持续更新 |
| 许可 | CC BY-NC | 美国联邦政府作品，公有领域 |
一句话概括：要「这款饼干含多少钠」，去 FoodData Central；要「大蒜里有哪些含硫化合物」，来 FooDB。前者的强项是广度与合规，后者的强项是分子层的深度。
6.5 该把它接在什么位置
对做多组学的人，FooDB 是「暴露端」的一张注释表：代谢组学找到的未知峰，可以来这里查是不是食物来源。对做营养流行病学的人，它是「把食物翻译成化合物」的词典。对做知识图谱的人，它是食物-化合物二部图的一个现成边集。
三种用法共享同一个前提：只用有浓度的那一小部分，且对浓度做分层处理。把它当作「全部食物成分的完整清单」来用，在任何一种场景里都会出错。
§7 质量与已知问题
7.0 阅读本节前的一个前置校正
讨论一个库的「质量」，先要确定它承诺了什么。FooDB 承诺的是「把文献与既有成分库里报道过的食物成分汇总到一处，并标注来源」。它没有承诺测定、没有承诺标准化、没有承诺完整。
按这个承诺衡量，它完成得不错：覆盖广、每条有来源、结构完整、可下载、可检索。按「测量数据集」的标准衡量，它几乎处处不及格：没有方法、没有误差、没有样本量、没有检出限。
绝大多数对该库的批评，本质上是拿第二把尺子量第一件事。这不是说批评不成立，而是说批评的落点应当是「别把它当测量数据用」，而不是「这个库做得很差」。
7.1 DAIMS 五维评分
| 维度 | 评分 | 依据 |
|---|---|---|
| 可发现性 | 强 | 有永久编号、有交叉链接、有结构检索、网页可直达 |
| 可访问性 | 强 | 免注册下载，多格式，CC BY-NC 明确 |
| 互操作性 | 中 | 结构标识规范，但名称与单位未归一，需外部映射 |
| 可复用性 | 中 | 许可清晰，但缺方法学文档与版本说明，复用成本高 |
| 可信度 | 弱至中 | 来源可标，但不可核；单位事故与部位混淆有实例 |
五维里最强的是前两项，这也是它能被广泛引用的原因；最弱的是最后一项，这也是它难以支撑定量结论的原因。
7.2 已知的、可枚举的偏差
| 偏差 | 表现 | 后果 |
|---|---|---|
| 存在性偏差 | 检出即入表，未检出不入表 | 越是研究得多的食物，化合物数越多，与真实组成无关 |
| 研究热度偏差 | 大蒜、绿茶、蓝莓等被反复研究 | 冷门食材的记录数被系统性低估 |
| 量化偏差 | 只有百分之一五左右的化合物有浓度 | 任何按化合物计的统计都被未定量部分稀释 |
| 区间压缩 | DUKE 只给上下限，取中值 | 高估常见，且方差信息丢失 |
| 部位混淆 | 含种子、果皮、茎叶等不可食部位 | 部分食物浓度被高估数倍 |
| 名称漂移 | 同物异名、异构体混同 | 去重不彻底会重复计数 |
| 单位残留 | ppm、微克、微摩尔混入 | 量级错误，最严重的可达百倍 |
这份清单不需要背，只需要记住一件事：任何一个从 FooDB 算出来的数，都同时背着这七种偏差。写论文时如果不提，等于默认它们不存在。
7.3 单位事故：一份可复查的案例
第三方在清洗 FooDB 时发现了一个可以完整复盘的错误链。
症状：蓝莓的维生素 K 在库中记为每百克三十毫克，而丹麦国家成分库是每百克零点零二毫克，相差一千五百倍。
原因：源头 DUKE 库以 ppm（即每公斤毫克数）记录该值，写作三十。FooDB 在折算为每百克时按毫克处理，数值未除以十，再被当作每百克毫克数写入，于是三十 ppm 变成了三十毫克每百克，放大一百倍。原始文献的实际测定值是每百克零点二六到零点三二毫克。
后果：任何用 FooDB 估算维生素 K 摄入的研究，若不清洗，蓝莓类食物的贡献会被高估两个数量级。同类问题在硒与烟酸上也被发现。
这个案例的价值不在错误本身，而在它说明错误的类型：不是随机噪声，而是系统性的换算失误，会沿着所有引用该值的下游分析传播。
7.4 八成以上没有数字
被广泛引用的一个估计是：FooDB 收录的营养化合物中，约百分之八十五从未被定量。这个比例与前面的大蒜案例一致——两千三百零六种里一百四十六种有值，约百分之六。
两个数字不矛盾，因为分母不同：前者按全库化合物计，后者按单一食物的化合物计。共同结论是，这个库的主体是「存在性」，不是「含量」。
对做机器学习的人，这一点决定了它能不能用作监督信号。把「有记录」当作「有含量」，会得到一个标签极度稀疏且非随机缺失的数据集——缺失与「研究热度」强相关，而非与「真实含量」相关。
7.5 它为何存在，又为何停住
它为何存在，答案在需求侧：营养流行病学需要一个比营养成分表更宽的化合物清单，而官方体系受方法学约束无法提供。FooDB 用聚合的方式绕过了这个约束，代价是把可靠性换成了覆盖面。这是一笔清醒的交易。
它为何停住，站内没有解释。可以观察到的事实是：数据停更已逾六年，版本号停在 1.0 且标着 Pre-release，此后再无更新公告。同一团队的 HMDB 仍在更新，说明停滞不是团队能力问题，而是这个项目的资源与优先级问题。
对使用者的直接含义是：把它当作一份有明确截止日期的历史快照，而不是一个仍在生长的资源。任何「最新数据」的期待都会落空。
§8 生态位与历史
8.1 沿革
FooDB 的思路可以追到阿尔伯塔食物代谢组计划：该计划对数十种极常见的食物做了系统的代谢组测定，用实验数据补上文献里缺失的部分。这批实验数据加上文献汇编，构成了库的初版。
方法学上，这个库没有一篇专属的建库论文。被引用最多的是二〇一一年发表在《农业与食品化学杂志》上的一篇综述，讨论食物植物化学数据库及其健康效应，FooDB 在其中作为案例出现。站点的引用指引也很直白：引用网址本身。
这一点值得在方法学部分说清楚：与 HMDB、DrugBank 各有正式论文不同，FooDB 缺少一份可引用的建库说明。想了解它的策展规则，只能读站内的说明页与合规声明。对于一个被大量论文引用的资源，这是明显的文档缺口。
8.2 三兄弟的分工表
| 维度 | HMDB | DrugBank | FooDB |
|---|---|---|---|
| 对象 | 人体内源代谢物 | 药物 | 食物成分 |
| 规模 | 二十五万条代谢物记录 | 万余药物记录 | 数万条化合物记录 |
| 每条内容 | 浓度、疾病关联、通路、谱图 | 靶点、相互作用、剂量、药代 | 结构、分类、食物来源、浓度 |
| 数据来源 | 实验测定与文献精读 | 药品说明书与文献 | 数百家汇编 |
| 更新 | 持续 | 持续 | 停在二〇二〇年 |
| 许可 | 开放，非商业为主 | 学术免费，商业授权 | CC BY-NC |
| 典型用法 | 代谢组学注释 | 药物重定位与相互作用 | 膳食暴露与食品化学 |
三行放在一起看，能看出团队的策略：把「小分子在人体内的三类角色」分别做成库，用同一套模板降低使用成本，用交叉链接把它们串成一条链。FooDB 是这条链的入口端，也是三兄弟里维护最弱的一个。
8.3 营养暗物质这个说法
二〇二〇年前后，「营养暗物质」成了一个流行比喻：我们对食物中绝大多数分子的了解，接近于对暗物质的了解——知道它们在那里，不知道它们是什么、有多少、做什么。
FooDB 是这个比喻最常被引用的证据。它的价值不在于证明食物复杂，而在于第一次把「复杂」量化成一个可数的清单：数万条记录，其中八成没有数字。这个清单让「未知」变成了可管理的对象——可以一条一条去补。
比喻也有副作用。把「未定量」等同于「未知功能」会夸大空白：许多未定量的化合物其实有充分的安全性资料，只是没有人在每种食物里逐一测过含量。空白更多是测量经济学的产物，不是知识的有无。
8.4 在 AI 时代的再定位
近五年，FooDB 最主要的增量用途不是营养学，而是机器学习。常见用法有三种：做食物-化合物二部图的预训练，做化合物性质预测的辅助特征，做食品推荐的内容侧表示。
三种用法都碰到同一个问题：边权（浓度）大面积缺失，且缺失不随机。直接把缺失当零，会学出一个「研究热度」模型而不是「成分」模型。可行的做法是把图结构（谁含有谁）与边权（含多少）分开建模，前者用全量边，后者只用有值的小子集。
这也解释了为什么这个停止更新的库仍有生命力：图结构部分的价值衰减很慢——大蒜含有槲皮素这件事，不会因为库不更新而变错；含量部分的价值衰减很快——新的测定方法会推翻旧值。
§9 使用指引
9.1 三种角色的路径
| 角色 | 第一步 | 关键动作 | 常见坑 |
|---|---|---|---|
| 营养流行病学者 | 下载 Content 表 | 食物名对齐到问卷编码，剔除不可食部位 | 直接用平均值算摄入，误差不可控 |
| 食品化学研究者 | 按化合物查食物 | 用结构标识去重，核对来源类型 | 把 DUKE 的区间中点当测定值 |
| 数据工程师 | 下载整包建图 | 分开建「含有」边与「含量」边 | 把缺失当零，学出热度偏差 |
9.2 一条最短的可用流程
第一步，下载整包，解压到本地。别指望网页端做批量导出。
第二步，读 Content 表，只保留有数值、有单位、有食物名的行。这一步会砍掉大半记录，剩下的才是可用的部分。
第三步，统一单位。先看 orig_unit 的取值分布，把 ppm、微克、微摩尔分别折算到毫克每百克，折算系数写在代码里，别凭记忆。
第四步，按结构标识而不是名称去重。名称层的同物异名会把同一个化合物拆成几条，直接影响任何计数。
第五步，按来源分层。至少把四家有定量数据的来源与其余来源分开，前者可用于定量，后者只可用于「存在性」。
第六步，做异常值筛查。同一食物同一化合物的多个来源值若相差两个数量级以上，先怀疑单位，再怀疑部位。
第七步，记录版本与清洗规则。库不再更新，但你的清洗脚本会变，写清版本才能复现。
9.3 引用方式
站点的要求很简单：引用网址。学术写作中更稳妥的写法是同时给出库名、版本、数据截止日期与访问日期，例如「FooDB, Pre-release 1.0, 数据截止 2020-04-07, https://foodb.ca/」。
如果用了具体的浓度值，建议在方法部分说明该值来自哪个上游来源（USDA、DTU、Phenol-Explorer 或 DUKE），因为同一个数值在不同上游的可信度差别很大。只写「据 FooDB」会把这份差别藏起来。
商业使用需另行取得授权，这一点在方法部分也应写明，尤其是企业内部的工具链。
§10 AI 使用声明
本词条由千方病案医学编辑部组织撰写，事实核对以站点公开页面为主，辅以第三方对该库的清洗研究。写作过程中未使用生成式模型编造数据；所有数字均标注了口径与出处，无法核实的部分明确写为「站内未披露」。
需要声明的局限有三条。其一，站点首页与说明页在核对期间对自动抓取返回了人机验证页，正文内容经检索索引取得，与直连所见可能存在细微差异，核对日期为二〇二六年十月二十九日。其二，库已停止更新，站内页面与下载包可能不同步，本词条以公开可查的下载包统计为准。其三，第三方清洗研究的数字基于二〇二〇年四月版，若维护方此后重新发布，相关数字需重新核对。
对本词条内容的使用建议：把它当作选型与理解的参考，不要当作数据字典。真正的字段含义以下载包内的表头为准，真正的许可以站点合规页为准。
常见误读（避坑清单）
| 常见说法 | 实际是什么 | 证据 |
|---|---|---|
| 「FooDB 收录了数万种食物成分，所以数万种都被确认存在」 | 那个数是字典表行数，其中五万余条为推定存在，四万余条属脂类 | 第三方对二〇二〇版下载包的统计与分类说明 |
| 「它和营养成分表一样，数字可以直接引用」 | 浓度是汇编值，同一组合常有多个来源值，站点取平均 | 站点说明与清洗研究的测定值比对 |
| 「没有浓度说明这种化合物不存在」 | 只说明没人在这个食物里定量过它，不说明它不在 | 大蒜两千余种化合物仅一百余种有浓度 |
| 「免费下载就等于可以随便用」 | 免费指访问，许可是 CC BY-NC，商业使用需授权 | 站点合规页的许可声明 |
| 「它是开放数据，所以可以被任意整合再发布」 | 部分整合项目因该许可而排除它 | 天然产物文献库的源筛选说明 |
| 「同一个化合物在不同库里编号不同，需要手工对齐」 | 三个同门库共用编号风格并互相链接，但编号本身不通用 | 站点交叉链接与编号规则说明 |
| 「它包含加工食品的配方信息」 | 只有粗粒度品类，无配料、无配比、无品牌 | 表结构中没有配方与品牌字段 |
| 「它是持续更新的活库」 | 数据停在二〇二〇年四月，版本仍标预发布 | 下载页标注的更新日期 |
| 「按名称合并就能去重」 | 同物异名与异构体混同普遍存在，须按结构标识去重 | 清洗研究报告的名称归一问题 |
| 「用它算摄入量只需乘一下消费量」 | 还需食物名对齐、单位统一、异常值剔除、来源分层 | 已发表的清洗与链接流程 |
| 「覆盖广意味着每种食物都研究得很透」 | 覆盖广度由研究热度决定，冷门食材被系统性低估 | 存在性偏差与量化偏差的分布 |
| 「谱图齐全，可以做未知峰匹配」 | 谱图覆盖面远小于化合物覆盖面，多数化合物无谱图 | 下载格式与谱图寻址方式说明 |
FAQ
Q1：FooDB 里的浓度数字是实验室测出来的吗？
不全是。它是聚合库，浓度来自它汇编的数百家来源，其中真正带定量数据的只有四家食物成分库。即便来自成分库，也常是二次汇编而非原始测定。站点对同一食物同一化合物取各来源平均值展示，下载表则保留全部原始行。
Q2：现在还能免费下载吗？
可以，且不需要注册或登录。站点合规页明确写明访问与下载不需要身份验证，整包提供 JSON、CSV、XML、SQL 等格式。访问门槛与许可是两件事：拿到数据不需要任何手续，但 CC BY-NC 的条款在下载那一刻就生效，非商业自由，商业需另行授权。
Q3：它和 HMDB、DrugBank 到底什么关系？
同一位研究者、同一个实验室、同一套模板的三个分支。HMDB 管人体内源代谢物，DrugBank 管药物，FooDB 管食物成分。三者共用编号风格与字段设计，彼此交叉链接。质量上不可等同：前两者的实验测定比例明显更高。
Q4：为什么各处引用的化合物总数差一个数量级？
因为数的是不同的层。字典层数万行，有浓度层一万余种，严格可用层数千种，早期文献还写过两万八千种。四个数字都对应真实存在的某张表或某个子集，混用时就会打架。引用时必须说清「数的是哪一层」。
Q5：能不能用它估算某人群的化合物摄入量？
可以，但要接受三道损失。食物名要手工对齐到膳食调查编码；浓度要从多个来源里挑一个或取平均；未定量的化合物只能记为零或缺失。已有研究走通了这条路，结论是可用的化合物数量远小于表内记录数。
Q6：它包含菜谱、配方或加工工艺吗？
不包含。数据只有食物与化合物两级，没有配料表、配比、工艺参数，也没有品牌与批次。加工食品以粗粒度品类出现，浓度多借用同类原料的数据。
术语表
| 术语 | 含义 |
|---|---|
| 食物成分库 | 记录食物中化学组成的数据库，官方体系以营养素为字段 |
| 营养素 | 有推荐摄入量与标准检测方法的成分，如维生素、矿物质、脂肪酸 |
| 化合物记录 | 字典表中的一行，代表一种被报道过的化学物质 |
| 浓度记录 | 事实表中的一行，代表某食物中某化合物的一个数值与一条来源 |
| 存在性数据 | 只记「含有」，不含数值 |
| 定量数据 | 带数值与单位的记录，本库中占比很小 |
| 推定存在 | 由分类或同属物种推断，未在本食物中直接分离鉴定 |
| 不可食部位 | 种子、果皮、茎叶等，非食用部分，库内未标注 |
| 上下限取中 | 来源只给最低量与最高量时，取其平均 |
| 每百克毫克 | 本库的规范浓度单位，写作 mg/100 g |
| ppm | 百万分之一，按质量计相当于每公斤毫克，折算易错 |
| 结构标识 | SMILES、InChI、InChIKey 一类字符串，用于跨库去重 |
| 交叉链接 | 指向其他库同一实体的链接，如 HMDB、PubChem、ChEBI |
| 预发布 | 站点对自身版本的标注，表示尚未定稿 |
附录 A：核心数字核对表
| 项目 | 数值 | 口径与出处 |
|---|---|---|
| 站点版本 | Version 1.0（下载页写 Pre-release 1.0） | 首页与下载页，核对日 2026-10-29 |
| 数据截止 | 2020-04-07 | 下载页标注 |
| 食物表行数 | 近千 | 下载页与第三方统计 |
| 化合物表行数 | 70,477 | 第三方对二〇二〇版下载包的统计 |
| 浓度表行数 | 五百余万 | 同上 |
| 营养素分组 | 数十 | 同上 |
| 聚合来源 | 三百余家 | 第三方清洗研究的方法部分 |
| 带定量数据的来源 | 四家 | 同上 |
| 有浓度值的化合物 | 一万余 | 同上 |
| 严格可用化合物 | 数千 | 同上 |
| 未定量比例 | 约八成五 | 二〇二〇年公开报道的估计 |
| 单食物化合物上限案例 | 大蒜两千三百余种，其中一百四十余种有值 | 公开报道与研究引用 |
| 商业授权 | 需单独申请 | 首页与合规页 |
| 下载门槛 | 免注册 | 合规页 |
附录 B：数字的来源分层
第一层，站内直接声明：版本号、更新日期、编号规则、许可条款、下载格式、字段规模。这一层的数字可以直接引用，因为它们是维护方的自我描述。
第二层，下载包统计：四张表的行数。这一层的数字取决于下载日期与文件版本，本词条采用第三方在二〇二三年对二〇二〇年版的统计，与站内可能存在的展示计数不完全一致。
第三层，第三方清洗结果：有浓度化合物数、可用化合物数、来源分布。这一层的数字取决于清洗规则，换一套规则会得到不同的值，因此引用时必须连带引用规则。
第四层，媒体与研究转述：从两万余到十万余不等的总量说法。这一层的数字最容易被误传，通常缺失口径说明，只适合做背景描述。
四层之间的关系是递减的可信度与递增的传播力。写作时把层标清楚，比追求一个「正确总数」更有意义。
附录 C：完整参考文献
- FooDB 站点首页与说明页，https://foodb.ca/ ，核对日 2026-10-29。
- FooDB 合规与 FAIR 声明页，https://foodb.ca/compliance ，核对日 2026-10-29。
- FooDB 下载页，https://foodb.ca/downloads ，核对日 2026-10-29。
- Scalbert A, Andres-Lacueva C, Arita M, Kroon P, Manach C, Urpi-Sarda M, Wishart DS. Databases on food phytochemicals and their health-promoting effects. J Agric Food Chem. 2011;59(9):4331-4348. doi:10.1021/jf200591d
- 食物成分数据清洗与膳食队列链接方法研究，PubMed Central PMC12637271，二〇二五年。
- 食品基因毒性物筛查研究（使用 FooDB 化合物表），Food Chemistry: Molecular Sciences，二〇二五年，其中给出各表行数。
- Wishart DS, et al. HMDB: a knowledgebase for the human metabolome. Nucleic Acids Res. 2009;37(Database issue):D603-D610. doi:10.1093/nar/gkn810
- 维基百科 FooDB 词条（含早期规模表述与建库背景），核对日 2026-10-29。
- 二〇二〇年关于「营养暗物质」的公开报道，含未定量比例与单食物案例。
附录 D：取数代码
import pandas as pd
BASE = "foodb_2020_04_07_csv"
#-- 1) 读字典表，当内存字典用
food = pd.read_csv(f"{BASE}/Food.csv")
comp = pd.read_csv(f"{BASE}/Compound.csv", low_memory=False)
print(food.shape, comp.shape)
#-- 2) 读事实表，只取需要的列
content = pd.read_csv(f"{BASE}/Content.csv",
usecols=["food_id", "orig_food_common_name",
"compound_id", "orig_source_name",
"orig_content", "orig_unit", "source_type"],
low_memory=False)
#-- 3) 先看单位，再决定换算系数
print(content["orig_unit"].value_counts().head(20))
#-- 4) 折算到 mg/100 g（系数需按实际单位表补齐）
FACTOR = {"mg/100 g": 1.0, "ppm": 0.1, "ug/100 g": 0.001}
content["unit"] = content["orig_unit"].map(FACTOR)
content = content[content["unit"].notna()].copy()
content["mg_per_100g"] = content["orig_content"] * content["unit"]
#-- 5) 同名多值：先看离散度，再决定取均值还是中位数
g = content.groupby(["orig_food_common_name", "orig_source_name"])["mg_per_100g"]
agg = g.agg(["count", "median", "min", "max"]).reset_index()
agg["spread"] = agg["max"] / agg["min"].replace(0, pd.NA)
#-- spread 超过 100 的行优先人工复核，多为单位或部位问题
suspect = agg[agg["spread"] > 100]
print(suspect.head(20))
#-- 6) 按结构标识去重，而不是按名称
uniq = comp.dropna(subset=["inchikey"]).drop_duplicates("inchikey")
print("按 InChIKey 去重后的化合物数:", len(uniq))
#-- 7) 只保留有浓度记录的化合物，做「存在」与「含量」两张边表
has_conc = set(content["compound_id"].dropna())
comp["has_concentration"] = comp["id"].astype(str).isin(has_conc)
print(comp["has_concentration"].value_counts())
编辑说明
核验时间：二〇二六年十月二十九日。
核验方式：读取站点首页、说明页、合规页与下载页的公开正文；读取第三方对该库的清洗研究与其引用的表行数；对同一事实至少取两处独立表述交叉比对。核对期间站点对自动抓取返回人机验证页，正文经检索索引取得，未做页面截图。
未覆盖内容：未下载全量数据包做逐行复算，因此所有行数均为第三方统计口径，而非自行重算；未逐条核对单个化合物页面的字段完整性；未验证谱图覆盖率的准确比例。
口径说明：本词条中所有「数万」「一万余」一类表述，均指附录 B 所列的具体层，不指「已确认存在的化合物总数」。凡遇跨口径比较，正文均已注明所数的是哪一层。
相关数据集导航
以下为站内 AI-Ready 数据集百科中与本词条共享多个主题标签的相关数据集，按相关度降序排列：
- anpdb — 共享标签：药物发现与化学 / 化学信息学 / 代谢组学 / 公共卫生与流行病学
- massbank — 共享标签：药物发现与化学 / 化学信息学 / 代谢组学
- hmdb — 共享标签：药物发现与化学 / 化学信息学 / 代谢组学
- meddra — 共享标签：药物发现与化学 / 公共卫生与流行病学
- lotus-ref — 共享标签：药物发现与化学 / 化学信息学 / 代谢组学
- comptox-dashboard — 共享标签：药物发现与化学 / 化学信息学 / 公共卫生与流行病学
- chebi — 共享标签：药物发现与化学 / 化学信息学 / 代谢组学
- zinc — 共享标签：药物发现与化学 / 化学信息学
- pdbbind — 共享标签：药物发现与化学 / 化学信息学
- toxcast — 共享标签：药物发现与化学 / 化学信息学
导航说明：本章节由全站统一标签体系自动计算生成（标签重合度算法），双向可达；点击链接可跳转至对应数据集词条。
