多源数据整合时，股票代码成了最头疼的问题

一个交易应用要接5家数据供应商，同一种资产却有12种命名方式——这不是技术难题，是命名权的战争。

从"简单调用API"到"代码翻译地狱"

TradingGoose团队最初的想法很直接：做一套通用数据连接器，让用户能自由切换Alpaca、Yahoo Finance、Alpha Vantage、Finnhub等多个数据源，既能按需选择，也能多源备份。

美股还算规矩。苹果股票在Alpaca是AAPL，在Yahoo Finance也是AAPL，复制粘贴就能用。

一迈出美股市场，混乱开始指数级膨胀。

同一只上海交易所的股票，在不同平台可能是：

外汇市场更离谱。EUR/USD货币对在Yahoo Finance叫EURUSD=X，在Finnhub变成OANDA:EUR_USD——前缀、分隔符全不同。加密货币是重灾区：BTC/USD在Alpaca是BTC/USD，在Yahoo是BTC-USD，在Finnhub是BINANCE:BTCUSD，在Alpha Vantage又是BTCUSD。

后缀系统也各自为政：^表示指数、.ETF标记基金、=X标记外汇对。有的平台prepend交易所标识，有的干脆不用分隔符。

没有统一的"canonical identity"（规范标识符），开发者就得为每个平台、每类资产维护一套字符串转换逻辑。供应商一改格式，全线崩溃。

开源世界早有先驱：两种截然不同的解法

CCXT选择了"动态归一化"。所有加密货币交易对被统一成BASE/QUOTE格式，比如BTC/USDT。无论交易所用BTCUSDT（Binance）、XXBTUSDT（Kraken的X/Z前缀）、tBTCUSD（Bitfinex的t前缀）还是BTC_USDT（Poloniex的下划线），CCXT都翻译成同一套标准。

每个交易所类维护一个hardcoded的commonCurrencies字典，把非标准代码映射到规范形式。仅Kraken就有30多条映射：XXBT→BTC、XETH→ETH、ZEUR→EUR。Bitfinex还要处理历史遗留：UST→USDT、LUNA→LUNC。每次交易所分叉或升级，字典得手工更新。

这套系统在加密货币圈内运转良好，但边界也很清晰：跨资产类别时力不从心，且维护成本随交易所数量线性增长。

QuantConnect的LEAN走了另一条路：为每个证券 engineered 一个永久、不可变的标识符。SecurityIdentifier把证券类型、市场代码、行权价、期权类型、到期日、看跌/看涨标记全部编码进一个64位整数，用嵌套模偏移实现紧凑存储。

Symbol类包裹这个底层ID，同时提供一个可变的Value字段——人类可读的股票代码。代码可以随时间变化（公司更名、合股），但底层标识符恒定不变。

处理代码变更和退市时，LEAN用CSV映射文件，每个证券一个文件。

TradingGoose的困境：没有现成答案

CCXT和LEAN代表了两个极端：前者轻量但局限于加密资产，后者精密但工程复杂度高。TradingGoose需要覆盖股票、外汇、加密货币多类资产，又不能承受LEAN级别的架构重量。

更麻烦的是供应商的"命名政治"。Yahoo Finance的EURUSD=X、Finnhub的OANDA:EUR_USD、Alpha Vantage的裸BTCUSD——这些差异不只是技术选择，背后是各平台的历史路径、商业协议和数据授权体系。

统一标识符意味着要在这些利益格局中建立"通用语"，而数据供应商未必有动力配合。

TradingGoose团队最终意识到，这个问题没有一次性解决方案。他们得在CCXT式的轻量适配和LEAN式的永久标识之间，找到适合自己业务规模的平衡点——同时接受一个事实：每新增一个数据源，就是新增一份需要持续维护的"翻译契约"。

这大概是多源数据整合最隐蔽的成本：不是API调用费，是命名权协调的无限游戏。