发布数据源：别人不用你的密钥也能跑你的组件

分享这件事上一直有个尴尬的缺口。你在自己的 OANDA 连接上做了一个漂亮的外汇图表，发布出去，第一个安装它的人看到的是连接 OANDA 以使用该数据——这等于是委婉地要求一个陌生人去开个券商账户，只为了看一张图。在实时屏幕上分享更糟：组件会冻结成一张缩略图。

解法不是把你的密钥借给谁。解法是把你的组件真正发出的那些读取请求，作为独立接口，发布在你自己的名下：

GET /<用户名>/api/w/<widget>/<endpoint>?symbol=EUR_USD&interval=H1

在发布对话框里打开它——发布只读数据源——没有自己连接的观看者就会读你的数据源，而不是被要求去连接。

三条规则，每一条都是一次拒绝

只有可以安全分享的读取。 十三个数据方法可以发布。其余的都被挡住，各有各的理由：account 和 positions 也是读取，但它们返回的是你的余额、净值、盈亏和持仓。order 和 closePosition 会动钱。upsert 和 delete 会毁数据。scrape 每调用一次就向第三方计费。而单纯的 http 本来就不带凭证，发布它只会造出一个挂着你名字的开放代理。

只有组件真正发过的调用。 组件运行时，它成功的读取会被记录下来，发布对话框会把清单摆给你看——来自 Binance 的 K 线 —— BTCUSDT，1h——作为你正在同意的那个具体东西。任何请求，只要索取你从未发布过的参数，或者索取你放宽范围之外的取值，都会在解密任何东西之前被拒绝。而那些本来就不该出现在 URL 里的参数——一段 SQL、一个查询向量——永远不会出现在里面：它们直接从存储中原样重放。

拒绝之间无法区分。 不存在的接口、超出取值范围的参数、以及你不属于的受众，返回的都是同一个 404。“某人是否有一个仅限好友的数据源”本身就是关于作者的信息，所以回应绝不会泄露它。

谁能读，以及你要付出什么

受众不是第四个容易忘掉的开关：它跟随那条公告帖——所有人、你的关注者，或者你的好友。私密公告会彻底关掉数据源，因为一条只有你能看见的公告，却支撑着别人在调用的接口，本身就说不通。

成本是最值得弄明白的部分，因为这也是最让人担心的部分。你选一个刷新间隔——每 30 秒、5 分钟、每小时或每天——那就是你的连接最多被使用的频率，无论多少人打开这个组件。所有读者共享同一份缓存副本。十个观看者和一万个观看者产生的上游调用次数一样，而且即使多个读者在同一瞬间都没命中缓存，每个时间窗内也只允许一次刷新真正跑起来。

你的密钥永远不离开服务器。你的余额、持仓和订单永远不会被发布。数据源与上架条目绑定：把组件下架，接口就停止服务。

观看者自己的连接永远优先

已发布的数据源是兜底，绝不是替代。如果打开你组件的人有自己的 OANDA 连接，组件用的就是他们的：他们的账户、他们的数据、他们的限额。只有在组件没能找到自己的连接之后，才会去查数据源；而查不到是静默的——他们看到的是平常那句连接该场所，而不是一个还要另外学的新错误。

这些接口走的是应用本来就带的那套场所适配器，所以已发布的数据源返回的数据形状，与你当初构建组件时看到的完全一致——覆盖目录中每一个已上线的场所，且不需要为任何一个写专门的服务端代码。

它刻意不做的事

• 共享的交易面板会画出图表，但不会画出账户面板。 那是屏蔽清单在起作用，不是缺陷。
• 符号选择器只提供你列举过的那些符号。 带自由输入框的组件会退化成一个固定集合。这是“不为你的券商造一个开放代理”所付的代价。
• 隐私模式下的作者无法发布数据源。 隐私模式里你的凭证只存在于本机的密封中，没有服务器持有它们，也就没有服务器能替你执行刷新。
• 分叉不会继承数据源。 数据源绑定在组件的血统上，因此每一份安装的副本解析到同一批接口，而分叉一个都解析不到。

它开起来只是件小事，但它改变了“发布”的含义：你分享出去的组件，现在是别人真的跑得起来的组件。

打开 Nexow，找一个你基于带密钥连接构建的组件，开着数据源把它发布出去。