首页 on FCANA

checklist

Sun, 19 Jul 2026 13:09:45 +0800

OSS + ESA + 服务端上线前检查单

架构目标：

reader.fcana.com -> ESA -> 书店 UI
reader-data.fcana.com -> ESA -> JSON / OPDS / 下载授权
reader-file.fcana.com -> ESA -> 私有 OSS

说明：P0 为上线硬门槛；P1 为强烈建议；P2 为上线后优化项。

0. 测试样本

准备一个带空格和中文的测试对象，用来发现路径编码问题：

bookshelf-prod/books/preflight/a b-中文.epub

记录：

Bucket：________________
Region：cn-beijing
Prefix：bookshelf-prod
文件域名：reader-file.fcana.com
数据域名：reader-data.fcana.com

A. OSS

编号	级别	检查项	检测方法	预期结果	结果
A01	P0	Bucket 地域	OSS 控制台	华北2（北京）	☐
A02	P0	Bucket 权限	OSS 控制台	私有，未开启公共读	☐
A03	P0	公共访问阻断	OSS ACL/Policy	无匿名读取权限	☐
A04	P0	Object Key	控制台搜索测试对象	完整 Key 含 `bookshelf-prod/`	☐
A05	P0	裸 OSS 直链	`curl.exe -I`	`403`，不能是 `200`	☐
A06	P0	RAM 写入权限	RAM Policy	仅目标 Bucket/Prefix；无管理权限	☐
A07	P0	服务端上传	上传测试文件	OSS 中存在且大小一致	☐
A08	P1	Content-Type	查看对象 Metadata	EPUB 为 `application/epub+zip`	☐
A09	P1	对象不可变	查看 Key 规则	更新后使用新 hash/版本路径	☐
A10	P1	删除保护	查看清理逻辑	不使用全桶 `sync --delete`	☐

Windows CMD：

curl.exe -I "https://BUCKET.oss-cn-beijing.aliyuncs.com/bookshelf-prod/books/preflight/a%20b-%E4%B8%AD%E6%96%87.epub"

通过：403 Forbidden。返回 200 时立即停止上线。

B. 服务端配置

编号	级别	检查项	检测方法	预期结果	结果
B01	P0	Endpoint	查看 Storage Profile	北京公网或可用内网 Endpoint	☐
B02	P0	Bucket	查看配置	只填 Bucket 名	☐
B03	P0	Region	查看配置	`cn-beijing`	☐
B04	P0	Prefix	查看配置	`bookshelf-prod`，无首尾 `/`	☐
B05	P0	CDN Base URL	查看配置	仅 `https://reader-file.fcana.com`	☐
B06	P0	下载模式	查看配置	阿里云 ESA HMAC CDN	☐
B07	P0	HMAC Secret	查看状态，不打印明文	与 ESA 使用同一密钥	☐
B08	P0	Secret 安全	搜 Git/日志/前端	无明文 Secret、AK、SK	☐
B09	P0	签名协议	检查代码	`exp + sig`，HMAC-SHA256，小写 hex	☐
B10	P0	时间戳	查看真实 URL	Unix 秒，不是毫秒	☐
B11	P0	路径一致	比较三处路径	OSS Key、CDN path、签名 path 完全一致	☐
B12	P0	特殊字符	生成测试 URL	无 `%2520` 或双重编码	☐
B13	P0	无 OSS 原生签名	检查 Location	无 `OSSAccessKeyId`/`x-oss-signature`	☐
B14	P0	下载授权	带账号请求	`302/307` 到 `reader-file`	☐
B15	P0	授权端点不缓存	查看响应头	`Cache-Control: private, no-store`	☐
B16	P0	未登录访问	不带凭据请求	`401/403`，无 `Location`	☐
B17	P0	越权访问	无权限账号请求	`403/404`，无 `Location`	☐
B18	P1	TTL	比较 `exp-now`	建议约 300 秒	☐
B19	P1	幂等入库	同 key 重复提交	只产生一个正式书目	☐
B20	P1	健康检查	请求 `/readyz`	`200`	☐

curl.exe -u "USERNAME:PASSWORD" -D - -o NUL "https://reader-data.fcana.com/download/BOOK_ID"

通过响应：

302
Location: https://reader-file.fcana.com/bookshelf-prod/...?exp=...&sig=...
Cache-Control: private, no-store

C. ESA DNS 与私有 OSS 回源

编号	级别	检查项	检测方法	预期结果	结果
C01	P0	DNS 记录	ESA 控制台	`reader-file` 已开启代理	☐
C02	P0	CNAME	`nslookup`	指向 ESA，不是 VPS IP	☐
C03	P0	HTTPS	`curl.exe -I`	证书有效且域名匹配	☐
C04	P0	源站类型	ESA 控制台	OSS，私有访问－同账号	☐
C05	P0	Bucket	ESA 控制台	与服务端上传 Bucket 相同	☐
C06	P0	回源授权	ESA 控制台	自动授权成功，只读回源	☐
C07	P0	不经 Nginx	查看 Nginx/流量	文件请求不进入 VPS	☐
C08	P1	静态网站冲突	OSS 控制台	未启用静态网站托管	☐

nslookup reader-file.fcana.com

D. ESA HMAC 旁路函数

编号	级别	检查项	检测方法	预期结果	结果
D01	P0	函数已发布	函数和 Pages	有生产版本	☐
D02	P0	旁路模式	路由配置	Bypass 已开启	☐
D03	P0	路由范围	查看路由	只匹配 `bookshelf-prod/books/`、`covers/`	☐
D04	P0	算法一致	比对代码	HMAC-SHA256、UTF-8 Secret、64 位 hex	☐
D05	P0	签名原文	固定向量验证	`encoded_path + exp`	☐
D06	P0	无签名	直接请求	`403`	☐
D07	P0	错误签名	改 `sig` 一位	`403`	☐
D08	P0	过期签名	使用旧 URL	`403`	☐
D09	P0	过远未来 exp	手工构造	`403`	☐
D10	P0	合法签名	服务端生成 URL	`200` 或 `206`	☐
D11	P0	中文/空格路径	测试对象	合法 URL 成功，篡改编码失败	☐
D12	P1	方法限制	POST/PUT/DELETE	`403/405`	☐
D13	P1	函数指标	指标页面	无持续脚本错误或 CPU 超限	☐

curl.exe -I "https://reader-file.fcana.com/bookshelf-prod/books/preflight/a%20b-%E4%B8%AD%E6%96%87.epub"

必须返回 403。

E. ESA 缓存

编号	级别	检查项	检测方法	预期结果	结果
E01	P0	文件缓存规则	查看规则	只匹配文件域名的 books/covers	☐
E02	P0	Cache Key 忽略 `exp`	查看规则	`exp` 不参与 Cache Key	☐
E03	P0	Cache Key 忽略 `sig`	查看规则	`sig` 不参与 Cache Key	☐
E04	P0	无全局参数冲突	查看全局设置	未开启冲突的全站忽略 query	☐
E05	P0	首次请求	合法 URL A	MISS 或首次回源	☐
E06	P0	第二次请求	同路径合法 URL B	HIT 或 `Age` 增加	☐
E07	P0	HIT 后仍验签	错误签名访问已缓存对象	`403`	☐
E08	P0	错误响应不长缓存	先错后对	合法请求不持续命中旧 403/404	☐
E09	P1	TTL	查看规则	不可变 hash 路径可长缓存	☐
E10	P1	刷新流程	刷新测试对象	能正确清除对应缓存	☐

最关键的三步：

合法 URL A -> MISS
合法 URL B（同路径、不同 exp/sig）-> HIT
错误签名 URL -> 403

错误签名得到 200 时立即停止上线。

F. Range 与大文件

编号	级别	检查项	检测方法	预期结果	结果
F01	P0	Range	请求 0-1023	`206 Partial Content`	☐
F02	P0	Content-Range	看响应头	`bytes 0-1023/总大小`	☐
F03	P0	Accept-Ranges	看响应头	`bytes`	☐
F04	P0	文件大小	HEAD/完整下载	与 OSS 对象一致	☐
F05	P1	Content-Type	看响应头	类型正确	☐
F06	P1	文件名	实际下载	中文名可用，至少有 ASCII fallback	☐
F07	P1	断点续传	中断后续传	不从头重新下载	☐
F08	P0	不经 VPS	观察网卡	VPS 无文件主体流量	☐

curl.exe -H "Range: bytes=0-1023" -D - -o range-test.bin "完整合法签名URL"

G. CORS（前端使用 fetch/Blob 时升为 P0）

编号	级别	检查项	检测方法	预期结果	结果
G01	P1	Allow-Origin	带 Origin 请求	`https://reader.fcana.com`	☐
G02	P1	Expose-Headers	看响应	暴露 Length、Range、Disposition 等	☐
G03	P1	Credentials	看响应	不依赖 Cookie 时不启用	☐
G04	P1	OPTIONS	预检请求	`200/204` 或确认业务不触发预检	☐
G05	P1	浏览器实测	UI 点击下载	无 CORS 报错	☐

curl.exe -I -H "Origin: https://reader.fcana.com" "完整合法签名URL"

H. 旧 ESA 规则迁移

编号	级别	检查项	检测方法	预期结果	结果
H01	P0	新下载端点绕过缓存	请求两次	每次重新鉴权/签发	☐
H02	P0	JSON/API 动态	查看规则	`/api/*` 不共享缓存	☐
H03	P0	OPDS 权限	两账号请求	内容按权限隔离	☐
H04	P0	旧规则不抢先	检查顺序和 Host	新旧规则互不覆盖	☐
H05	P0	旧 Authorization Cache Key	查看匹配范围	不作用于 `reader-file`	☐
H06	P1	旧链路可回滚	保留配置	观察期内可切回	☐
H07	P1	协议接口无 JS Challenge	Koodo/KOReader 实测	返回 XML/302，不返回 HTML	☐
H08	P1	管理 API 未全放行	查看 WAF	仍有正常安全防护	☐
H09	P2	清理旧规则	稳定后执行	删除旧下载缓存和 Koodo 白名单	☐

I. 端到端

编号	级别	检查项	检测方法	预期结果	结果
I01	P0	上书	上传测试 EPUB	任务成功、对象进入 OSS	☐
I02	P0	JSON	请求 catalog	书目和下载入口正确	☐
I03	P0	OPDS	客户端/curl	acquisition 指向新授权端点	☐
I04	P0	UI	浏览器	封面、分类、下载正常	☐
I05	P0	跳转链	点击下载	`reader-data` -> 302 -> `reader-file`	☐
I06	P0	完整性	比较 hash/打开 EPUB	文件完整可读	☐
I07	P0	权限隔离	无权限账号	UI/JSON/OPDS/下载均不可越权	☐
I08	P0	隐藏/删除	隐藏书目后重试	新请求立即不可见；旧 URL 到期失效	☐
I09	P1	客户端兼容	Koodo/KOReader	能下载、识别文件名和格式	☐
I10	P1	移动端	手机浏览器	能下载或打开系统分享	☐
I11	P1	监控	下载大文件	ESA/OSS 有流量，VPS 无主体流量	☐

J. Go / No-Go

以下任意一项出现，立即 No-Go：

☐ OSS 裸直链返回 200
☐ reader-file 无签名返回 200
☐ 错误签名在缓存 HIT 后返回 200
☐ OSS Key、CDN path、签名 path 不一致
☐ 空格或中文路径发生双重编码
☐ 服务端生成 OSS 原生预签名参数
☐ 下载授权 302 被共享缓存
☐ 无权限用户取得 Location
☐ Range 不返回 206
☐ 文件主体流量仍经过 VPS
☐ Secret、AK、SK 出现在 Git、前端或日志
☐ 新 ESA 规则被旧规则覆盖

允许上线的条件：

☐ 所有 P0 通过
☐ P1 失败项均有风险说明和处理日期
☐ 已备份数据库、服务端配置和 ESA 规则
☐ 已完成一份真实 EPUB 的完整端到端下载
☐ 已完成“缓存 HIT 后错误签名仍 403”测试
☐ 已记录回滚操作

K. 推荐上线顺序

1. 备份旧配置
2. 上传测试对象
3. 验证 OSS 裸直链 403
4. 接入 reader-file 私有 OSS
5. 发布 HMAC 旁路函数
6. 验证无签名/错误/过期均 403
7. Cache Key 忽略 exp 和 sig
8. 验证 MISS -> HIT -> 错误签名仍 403
9. 验证 Range 206
10. 服务端启用新 Storage Profile
11. 上传真实测试刊物
12. 验证 JSON、OPDS、UI、302 和完整下载
13. 小范围切换
14. 观察至少 24 小时
15. 再清理旧 Koodo ESA 规则

L. 回滚

1. 暂停新上书
2. 下载入口切回旧端点
3. 恢复旧 Storage Profile
4. 保留 OSS 新对象，不批量删除
5. 禁用 reader-file 函数路由
6. 恢复旧 ESA 规则
7. 排查 prefix、编码、HMAC、Cache Key 和规则优先级

回滚时不要公开 Bucket，也不要为了临时可用而关闭 HMAC 后让文件域名裸奔。

UNC 01 - Briefly Intro

Sat, 11 Jul 2026 19:31:00 +0800

做跨境电商和B2B外贸，你平时去哪里找宏观选品数据？

花几万块买行业研报？还是全凭经验盲猜？其实，全球最权威的进出口底层数据，联合国早就向全人类免费开放了，只是 90% 的人不知道怎么用。

这个系列，我们从零开始，从网页查询学习到 Python 自动化，以该数据库为蓝本建立你自己的分析体系。

1. UN Comtrade 入门篇

1.1什么是UN Comtrade ？

United Nations Commodity Trade Statistics Database，即联合国商品贸易统计数据库（本文后称UNC）是全球最全面的全球贸易数据平台，按产品和贸易伙伴汇总了详细的全球年度和月度贸易统计数据，供各国政府、学术界、研究机构和企业使用。它汇集了全球近200个国家和地区的官方海关进出口统计数据，数据最早可追溯到1962年。所有的商品都通过国际标准的分类系统（在本文中，通常为HS编码*）进行分类。

UNC 是一个宏观市场分析工具。对于B2C外贸而言，它主要适合解决以下几类外贸问题：

A) 我的产品该卖给谁? 通过输入你产品的 6 位 HS 编码，你可以查到产品的流动情况，包括进口国、出口国和贸易额。这也是这个系统最核心的用途。用这些数据我们即可回答一系列宏观问题，包括市场集中度，买卖方需求，或是寻找潜力市场。 B) 我面临哪些国家的竞争？ 通常来说即使是制造业大国，在某些产品的生产和运输上也敌不过某些小国（即所谓比较优势理论）。通过该平台，您可以查阅到主要的产品来源地、产品生产国的市场占有率，为你即将开展的商业行为作参考。 C) 当地市场的接受价格是多少？

请注意：UNC不能、也不应该作为微观外贸的决策。它可以告知您“橡胶制品正在美洲热销”，但是它不能告诉您“我应该在 Amazon 平台销售剑匠零鼠标垫就一定能成功。” UNC最适合在外贸立项前期、制定年度出口战略、开拓新市场时使用。它能帮你从宏观层面指明方向，而具体的客户开发则需要配合其他工具（如海关提单数据、领英等）结合使用。

对于学者或是希望进行宏观数据分析的读者而言，该数据库提供了丰富的国与国之间贸易数据。你可通过该网站数据把握全球产业链转移与宏观趋势，也可为微观决策做参考。有很多高级的数据分析方法可供您快速、自动化的达成以上目标。我们将在后续教程中逐步揭示。

不过，在开始之前，我们要提到该数据库自身的一些局限性：

A)没有买家/卖家信息：它是宏观统计数据，你查不到具体的进口商名字、出口商名字、联系方式或提单信息。如果你需要找具体的客户邮箱和公司名，需要购买商业化的海关提单数据。 B)存在数据滞后：各国向联合国上报数据的速度不同。部分发达国家按月更新，但很多发展中国家的数据通常滞后几个月甚至一年（通常只能查到上一年的年度数据）。 C)HS编码的位数限制：国际通用的 HS 编码只有6位是全球统一的。7位及以上的编码各国都不一样，因此在UNC上进行跨国比较时，最多只能精确到6位编码（这可能会导致产品大类稍微偏宽泛）。

*注1：为什么通常是HS？HS (Harmonized System 协调制度)是全球通用的海关商品编码。全球统一到前 6 位。虽然在接下来的演示中还有按加工程度分类的SITC和按经济用途分类的BEC出现，SITC是按初级产品、工业制品两大项及下一级子项计算指数；BEC是顶层经济类别、最终用途、加工程度等维度划分商品并计算指数。但我们几乎不会用到这两项。在用到时，我们会加以详细说明。请读者留意。

影单

Sat, 11 Jul 2026 19:27:53 +0800

本页面简单记录一些我看过的电影、电视剧。

2026年

影片名	一句话剧情	观影时间	观影体验
龙猫	宫崎骏经典风味	2026.7.7,动车卧铺	经典老片😋😋爽之
泰迪熊(电视剧版两季)	真人版恶搞之家	2026.5-2026.7,陆陆续续看完的	爆米花剧，随便看看打发时间用的。
泰迪熊2(电影)	本质打反派	2026.7.6，长沙	电影版的主人公剧情和电视剧版本的不一样，但是内核是没差的。看这个系列最好还是懂一些西方冷门梗。

我的记账方法

Sat, 11 Jul 2026 18:01:59 +0800

记账是人之常情，对穷人来说亦是如此。我从拿到第一笔零花钱的时候就开始思考怎么记账，之前甚至用过那种加锁的本子🧐，但是总是草草收场。

后来我反思了一下造成这个问题的核心原因，我发现核心问题大概就是由于过于追求掌控欲，导致一切太麻烦了。

人总是想记录自己的每一笔开支，从昨天买的柠檬水到百万房贷的利息。但事实上，大部分的生活开支并不会成为一个很严重的的问题，也即所谓“吃饭穷不了”。

基于此，我和GPT 5.6激情探讨了一晚上，得到了以下这个最新的，（我个人认为）言之有理并且启动成本不高的记账方法。发布出来分享。

收付实现制

收付实现制，又称“现收现付制”或“现金制”，是指收入在实际收到现金时确认，费用在实际支付现金时确认，不考虑相关经济业务是否应归属于本期。其核心原则是：凡在本期实际收到或支付的款项，无论发生时间早晚或是否应由本期承担，均作为本期的收入和费用处理。 By Copilot

我们的记账方法，也正是基于这种思想实现的。这有助于解决一个生活中常见的痛点：你买的货币基金、理财、各种账户之间左手倒右手，要区分这些开支简直是太难了，因为在各类流水中都有所体现。所以我们假定以下公式：

基于这一公式，每个月的全部净资产就很好统计了。

地基环境搭建

首先打开一个空白Excel表格。先统计一下基本信息：

再新建一个工作簿，整理一下刚性支出：

再新建一个工作簿，整理一下每个月的基本状况：

其中以下几列使用了公式：

列	公式
I2	=IF(COUNT(C2,G2)<2,"",C2+SUM(D2:F2)-G2)
J2	=IF(I2="","",I2-N(H2))
K2	=IF(J2="","",J2/DAY(EOMONTH(DATE(A2,B2,1),0)))
C3	=IF(G2="","",G2)

向下拖条，让Excel自动复制。完毕。结束了。

每个月的实操怎么做？

第一期输入一次月初资产，以后每个月调整E F G H四列数字就可以。

场景1：当月出去旅游消费1000元。没有收入。

月初	月末	非常态支出
10000	6000	1000

自动推算可以得到当月常态日均消费约100元，也已经是很高的级别。

场景2：当月支付飞机票2000元，单位报销。

月初	月末	外部额外流入	非常态支出
10000	8000	2000	2000

自动推算可以得到当月常态日均消费约64.52元，就已经像合理的方向发展了。

小结

这个方法的核心逻辑就是：

以收付实现制为主、净资产变动校验为辅的个人消费估算方法。通过月初净资产、外部流入、投资收益与月末净资产之间的差额，反推当期总消费；对于旅游、大额设备采购等非常态项目另行调整，以观察常态消费基线。

维护成本低、能看长期趋势、不会陷入逐笔记账。简单可行。立马动手试试吧。

UN Comtrade 教程(3) - First EXCEL QUEUE

Fri, 10 Jul 2026 18:46:22 +0800

UN Comtrade系列的第三篇文章。前两篇文章我们回答了什么是UN Comtrade,怎么使用UN Comtrade进行第一次查询的问题，接下来是时候解答第三个问题了。我们要这些数据有什么用？应该怎么用？

本篇问题：如何使用EXCEL 读取UN Comtrade的首次查询

3.1 下载UN Comtrade的第一个查询结果

在页面上点击Preview - Download,就可以下载到数据了。

本文接下来将开始以此查询为基础，分析巴西向全世界出口咖啡豆的报告。

示范文件下载

就以这个示例查询结果来说，我们可以看到这样一些表头：

typeCode freqCode refPeriodId refYear refMonth period reporterCode reporterISO reporterDesc flowCode flowDesc partnerCode partnerISO partnerDesc partner2Code partner2ISO partner2Desc classificationCode classificationSearchCode isOriginalClassification cmdCode cmdDesc aggrLevel isLeaf customsCode customsDesc mosCode motCode motDesc qtyUnitCode qtyUnitAbbr qty isQtyEstimated altQtyUnitCode altQtyUnitAbbr altQty isAltQtyEstimated netWgt isNetWgtEstimated grossWgt isGrossWgtEstimated cifvalue fobvalue primaryValue legacyEstimationFlag isReported isAggregate

我们接下来分层次拆解。

3.1.2 精挑细选

本来这一部分我想先从“删”开始介绍各个表头含义的，但是后来我想到Excel中一个很好用的功能：数据透视表。我们接下来用几个实际的Case来阐释各主要列表的经济含义。总体来说：我们不删无用的，而是先挑选有用的。

现在就有一张数据透视表了。问题在于，哪些是给人看的，哪些是给机器读的？

这里有一个标准可供区分：

以 Code 结尾的，通常是给机器或系统识别的数字代码（比如国家代码 156 代表中国）。以 Desc (Description) 结尾的，是给人看的纯英文全称描述（比如 China）。以 ISO 结尾的，是国际通用的 3 位字母缩写（比如 CHN），非常适合后期在地图报表上画图用。

UNC 02 - First Attempt

Thu, 25 Jun 2026 15:49:18 +0800

2.1 认识UNC查询主界面

工欲善其事，必先利其器。

掌握以下这些查询术语，让你的数据查询之路如虎添翼。

作为正式教程的第一部分，我们开始吧。

作为全系列教程的第一课，相信不少人之前已经进入过 UNC的高级数据查询页面。或许是误打误撞，或许是有意筹划，但大多数人第一时间进入这个页面，很显然会是一头雾水：我在看什么？我要干什么？

我们接下来就来一步一步解决这些问题。

2.1 认识UNC查询主界面

截至本文成稿，UNC主界面长这样：

我们来一步一步拆解各项参数，帮助阅读此页面的读者完成第一次自主查询。相信我，很简单，读完本文后都能做到。 如果你愿意的话，也可以打开一开始的页面一起做。

2.2 TYPE OF PRODUCT(商品种类)

正如我们一开始向大家展示的，商品种类(TYPE OF PRODUCT)有两种：商品贸易(Goods) 和服务贸易(Service)。 商品贸易和服务贸易适用完全不同的查询标准和查询参数。因此我们接下来将分为两个小节，向读者讲解完整的查询步骤，让大家完成自己的第一次查询。

2.2.1 基于商品贸易的数据查询

如果你想查询商品贸易数据，请跟随以下的步骤选择每一条参数。

1.Frequency(频率)

Annual(年度) / Monthly(月度)

知识穿透：看宏观选大市场：选 Annual。年度数据最全、最准，适合做 3-5 年的趋势分析。看淡旺季做备货：选 Monthly。但要注意，很多国家（尤其是发展中国家）的月度数据上报非常滞后，甚至缺失。

2. Classifications（分类标准）

HS / SITC / BEC。 > 知识穿透：目前阶段，请锁定 HS。 > HS是全球通用的海关商品编码。全球统一到前 6 位。比如 090111 代表“未焙炒的咖啡豆”。在国内出口报关用的前6位，和美国海关接收时看到的前6位是一模一样的。而后两位各个国家都不同。

3.HS Commodity Codes (HS代码)

可以通过第三方网站查询HS编码。搜索引擎搜索"HS编码"即可。依然请注意：前6位是一模一样的。而后两位各个国家都不同。

4. Periods (year, month)

报告期限。需要注意，某些发展中国家上报数据可能会有缺失或延迟，这是正常现象。

5. Reporters、Partners和Trade Flow三元组(重中之重)

Reporters，是指（报告国/申报国）；Partners是指（贸易伙伴国）；Trade Flow有两个方向我们举一个第一人称的例子来理解这个问题：

现在中国向美国出口5公斤大米。 A.Reporter是中国，从中国的视角（第一人称）来看，我向美国出口 5kg 大米。那么Partner就是美国，显而易见；Trade flow 就是Export. B.但是你如果从美国的视角来看，进行一下视角转换呢？Reporter是美国，中国向我进口 5kg 大米。站在美国的视角来看，我的Partner就是中国了！显而易见此时Trade Flow就是Import.

5.1.高级玩法A：商品贸易的镜像数据

以后我们用 Python 处理数据会发现，查法A和查法B的金额往往对不上（因为运费、关税、统计口径甚至虚报等原因）。查法B被称为查法A的 “镜像数据” 。当某些国家（如战乱国）不主动上报数据（Reporter为空）时，我们就必须利用其他国家作为 Reporter 反向推导。

6.Periods（时间周期）

你要查哪一年的数据？

知识穿透：可以多选。比如同时选中 2021, 2022, 2023。

2.2.2 几条常见的坑点

1.World 与 All 的“影分身之术”（数据无故翻倍之谜）

你下载了一份中国对全球各国的出口数据，丢进 Excel 做数据透视表求和，或者放到 Power BI 里拉了一个柱状图。结果老板一看数字大怒：“中国去年的出口总额怎么可能比全球 GDP 还高？！”

这主要是PARTNER参数造成的。

Partner = All，联合国会老老实实把中国对美国、对日本、对德国……等全球近 200 个国家的交易一行一行地全部给你拉出来。

Partner = World（全球汇总计，代码为 W00）：它是联合国帮你提前算好的一行 “总计数据”。它代表中国对全世界所有国家出口额的总和。

最佳实践:

在 GUI 阶段如果只想看宏观大数，Partner 就只选 World；如果要分析各个国家的排名，就选 All，千万不要在搜索框里把两个同时勾上。

在数据清洗阶段在 Excel 里，养成习惯第一步就把 Partner 列里的 World（或国家代码 W00）筛选并删除/隐藏；在 SQL 或 Power BI 里，写死一个过滤条件：WHERE Partner <> ‘World’。

2.不可名状的 2nd Partner（不要瞎选，All 和 World 依然致命）

这其实是第一个坑的“变种”，但在处理更复杂的供应链溯源时极其致命。

知识点穿透（什么是 2nd Partner）：正常的贸易是 A国卖给 B国。但有时存在“转口贸易”或“原产地追溯”。2nd Partner 通常指的是 “原产国”或“发货国”。

虽然初期不涉及，但有些人看着这个下拉框，强迫症发作，顺手就选了 All 或 World，觉得“反正是全选，数据更全”。

一旦你在这里瞎选，你的数据维度会被瞬间打碎。

如果你选了 Partner = USA 且 2nd Partner = All，你会发现原本一行“中国出口到美国”的数据，裂变成了几十行（因为这批货里可能包含了原产自不同国家的零部件）。

更可怕的是，如果你在 2nd Partner 里混选了 All 和 World，再结合上面提到的求和翻倍问题，你的数据可能会变成原值的 3倍、4倍甚至错乱无穷大。

最佳实践:只要不是为了专门研究复杂的原产地或转口贸易，2nd Partner 请坚决地保持默认的 World。

纸上得来终觉浅，绝知此事要躬行。

了解了基本参数和常见坑点后，请打开 UNC的主查询页面，尝试独立完成以下三个循序渐进的实战任务。这不仅能帮你巩固本章所学，更是为了接下来引入代码自动化查询打下坚实的业务逻辑基础。任务一：经典跑通（商品贸易基础）

背景：假设你是一家国内咖啡豆贸易商的数据分析师，老板想了解 2023 年中国向美国、德国、日本出口了多少“未焙炒的咖啡豆”。

TYPE OF PRODUCT：Goods

Frequency：Annual

Periods：2023

Reporter：China

Partner：USA, Germany, Japan（防坑提示：这里请手动输入并勾选这三个国家，千万不要选 All 或 World）

Trade Flow：Export

HS Code：090111 🎯 验收标准：点击查询或下载数据后，你应该能看到清晰的 3 行核心数据，并且能够分别读出对这三个国家的 Trade Value (US$)（贸易额）和 Net Weight（净重）。

任务二：视角转换（寻找“镜像数据”）

背景：接着任务一，我们现在要用“镜像数据”来做个交叉验证，看看美国海关那边的统计口径和中国海关的数据差异有多大。

参数修改：保持其他参数不变，但这次请将 Reporter 改为 USA，将 Partner 改为 China，并将 Trade Flow 改为 Import（进口）。

思考题：这是美国视角的“从中国进口咖啡豆”。

🎯 验收标准：对比一下任务二（美国报进口）和任务一（中国报出口）中，中美两国关于这批咖啡豆的 Trade Value (US$)。你会发现这两个数字并不完全相等。

知识穿透：为什么对不上？因为通常出口国按照 FOB（离岸价）申报，进口国按照 CIF（到岸价，包含运费和保费）申报，外加在途时间跨年等因素。这就是真实商业世界的数据常态。

任务三：虚拟出海（服务贸易初探）

背景：你的朋友在做软件外包和游戏出海，想看看中国近两年在“IT与信息服务”领域的整体出海大盘数据。

TYPE OF PRODUCT：切换为 Services

Frequency：Annual（回忆一下，服务贸易没有月度数据）

Periods：2022, 2023

Reporter：China

Partner：World（防坑提示：我们只看宏观大数，所以选 World 总计即可）

Trade Flow：Export

EBOPS分类：在搜索框中寻找 Telecommunications, computer, and information services 相关的选项。

🎯 验收标准：成功拉出这两年的数据。请亲自观察一下数据表，确认 Net Weight 和 Qty 这几列是不是如同我们所说的，全都是空的？

更新规则

Mon, 22 Jun 2026 18:47:03 +0800

更详细的更新打算。

我准备集中每半年的更新*计划到一个总集页面，刷新时间是3月和9月。

取3和9一部分原因是按照春秋季学期（也是大部分人十几年的学生经验）来排布，不在年初不在年末，正好适合总结和复盘，进行中期调整；

具体更新内容分三部分：

a.一个系列，总集，或是需要深度展开的内容。

一篇写不下，或可能随着时间发展滑移，所以需要动态更新；或者是固定时间更新的文章（虽然我说过可能不会这样做，但是万一呢）

b.由突然发生的事（上文的碎片记录）转化而来的感想。

此类内容多为单篇拓展，可能较长也可能较短。但是品质是有保证的，还是那句话，绝不辜负大家的时间、精力和智商；

c.为服务于特定功能或目的临时加更的文章。

这类文章随缘发。

*:为什么是半年呢？我觉得按季度来总结过于琐碎了，何况有些比较大的项目可能一个季度真写不出一两篇；按年度又太长了，半年比较合理。

我目前也不怕博客没访问量，也不怕有人因为我一直不更新社媒而把我忘记。实际上我准备把社媒的三天可见取消，其他内容全部删除，只留下通往博客首页的链接。如果你只是抱着窥探或者猎奇心理来到我的社媒，无可奉告。请回吧！如果你带着深度观测的欲望来到我的网站的话：一座无限长宽高的墙上，有一扇门。

我所做的就是充分尊重大家的时间、精力和智商，完善门后的内容，降低门的门槛，让你不后悔打开这扇门。可能你不满意门后的内容或者思想，但我保证你不后悔。

至少你现在知道了。

创刊号

Mon, 22 Jun 2026 15:28:47 +0800

1.合规全新启航。

六年前我还是个未成年公民，缺乏各种KYC的要素，也就没能顺利完成国内的域名备案认证，只能用国外的github搭点服务器玩玩。稳定性不足。这次的架构选择了轻量付费、具有SLA保证的全新服务架构，且启用了备案域名，对国内访客友好，标志着网站运营走向长期规范化；

2.软件架构升级。

以前选择博客架构起手就是wordpress或者什么静态的Gridia hosted on github pages,可玩性很高，可持续性不足。这次选择了Hugo+手码一套CI/CD部署工具，提高了在线稳定性，减少攻击暴露面，也让国内服务更可持续。

3.生产内容规划。

以前博客抱着做着玩的心态来做，也就没有很认真的规划内容产出。现在相较于更常见的“我一定要多久更新一次”这种硬flag,新版架构我准备采用“schedule”，计划表更新周期，先有了灵感和选题之后再规划更新时间，以内容产出为计量单位而不是以时间作为硬性的计量单位，呈现出来的效果大概就是“更新计划表”一类的东西。这个只是暂时的，可能后期还要进行规划调整。

新架构，新产出，新收获。“新"博客，我们来了。