多币种汇率监控系统实战：从API选型到阈值告警

1. 先聊聊思路：为什么用API做多币种汇率监控

1.1 汇率监控到底在解决什么问题

先别急着写代码，想清楚一个问题：你盯汇率是为了什么。是做跨境电商核算成本？是外贸报价单需要实时更新？还是个人在做多币种资产配置，想等一个合适的换汇节点？不同的目的，对监控系统的要求完全不一样。

如果是做外贸，你可能需要的是某个货币对在特定时间段的波动提醒，比如USD/CNY突破某个心理价位告诉你一声；如果是做财务对账，你可能每天固定拉一次收盘价就行；如果是做量化交易，那要求就高多了，可能要秒级延迟、历史K线、多家数据源交叉验证。

我当年第一次做汇率监控，是帮一个做跨境电商的朋友盯EUR/USD和USD/CNY。他每周要更新一次商品售价，手工去银行网站查汇率，费时费力不说，不同银行的牌价还不一样，选错了一个点就是几千块钱的利润差异。

后来我意识到，所谓的“多币种汇率监控”，本质上是三个问题：取数要稳定、换算要准确、提醒要及时。取数稳定靠API，换算准确靠数据结构设计，提醒及时靠调度和通知渠道。把这三点拆开，逐个击破，整个系统就清晰了。

1.2 三种取数方案对比，为什么API胜出

做汇率数据获取，主流方案大概有三种：直接爬银行或财经网站的页面、对接外汇API、自己接交易所或银行间市场的原始数据源。我三种都试过，说说实际感受。

先说爬虫。看到哪家银行网页上有牌价表，直接requests去抓HTML，再正则或者xpath解析。听起来简单，但真实情况是：页面结构说改就改，今天能抓到明天就报错；有些网站有反爬机制，访问频繁了直接封IP；更麻烦的是，牌价数据是异步加载的，你要先分析接口，模拟请求头，有时候还要处理加密参数。投入产出比极低，而且数据源不正规，出了问题你根本说不清楚数据是哪来的。

再说自己接原始数据源。银行间市场、SWIFT这类渠道确实权威，但你个人开发者根本拿不到接口权限，就算拿到了，接入成本和学习曲线也让人劝退。这属于企业级方案，个人玩不转。

API方案是最平衡的选择。你只需要注册一个账号，拿一个API Key，按文档拼一个URL，发GET请求就能拿到结构化的JSON数据，解析成本极低。正规的外汇API服务商通常有多个数据源交叉校验，数据质量有保障；限流、Token刷新这些基础设施人家已经做完了，你只需要关注业务层。唯一要付出的是订阅费，但大多数服务商都提供免费档，个人学习和测试完全够用。

所以我在实际项目中，首选的方案就是API。下面详细讲讲怎么选、怎么用、怎么把这个监控系统落地。

2. API选型与准备：免费还是付费，怎么选不踩坑

2.1 主流外汇API对比与选型

市面上的外汇API服务商很多，有专做外汇的，也有做加密货币顺便覆盖法币的。我实际接触和测试过的主要有这几个：

选择的关键不是看谁支持的币种多，而是看三点：更新频率够不够你用、免费额度够不够你的轮询频率、数据源是否覆盖你关心的主流货币对。

如果你只需要每日一次的快照，选免费用量大的就行；如果你要盘中实时监控，那必须选提供实时或分钟级更新的付费档，免费档一般是小时级甚至日级更新，用来做实时提醒会误事。

注意：不少免费外汇API存在一个隐性坑——报价有延迟，通常是15到30分钟。如果你做的是短线交易级别的监控，这个延迟是不可接受的，必须升级到付费档。但如果只是做日报、周报级别的汇率监测，免费档完全够用。

2.2 拿到Key之后，先搞清楚限流和数据规范

选定了服务商、注册完拿到API Key，大部分人的第一反应是赶紧请求一下试试，这没错，但我在实际项目中建议你先花十分钟做三件事，能省掉后面一堆麻烦。

第一件事是看文档里的限流规则。限流通常分两种：请求频率限制（比如每秒最多2次）和月度配额限制（比如每月1500次）。请求频率限制主要影响你连续拉取多个货币对时的节奏，月度配额限制影响你的轮询间隔设计。打个比方，你每月1500次，如果一天拉一次，1500次够你用50个月；但如果五分钟拉一次，一个月就超了。所以先算清楚账，再设计轮询策略。

第二件事是确认数据更新的时间戳。外汇API返回的数据一般会带 timestamp 字段或者 date 字段，你要确认这个时间戳是报价时间还是服务器响应时间。有些服务商在免费档返回的是上次更新的缓存数据，并不是当前实时价格，你自己要心里有数。

第三件事是搞清楚基础货币和报价货币的关系。大多数API的请求格式是 base=USD&symbols=CNY,EUR,JPY，意思是“以美元为基础货币，获取美元兑人民币、美元兑欧元、美元兑日元”。但不是所有API都支持任意货币作为基础货币，免费档通常只支持固定的几种，一般有USD、EUR。选型的时候要特别留意这一点，否则当你需要“USD兑CNY”和“JPY兑CNY”的时候，目标货币不是基础货币，可能就得绕一圈换算。

2.3 币种代码体系与数据精度，这些小坑要提前知道

货币代码在国际标准里是ISO 4217，比如USD、EUR、CNY、JPY，这个没得说。但实际项目中，有几个细节非常容易踩坑。

第一个坑是加密货币和法币混在一起。很多聚合类API除了法币，还支持BTC、ETH等加密货币。如果你的业务只关心法币，建议在请求参数中明确过滤，不然解析响应的时候，混进来的币种会让监控程序异常。

第二个坑是报价精度。同样是USD/CNY，有的API给4位小数，有的给6位。如果监控阈值设得很窄，精度差异可能导致误报。实测下来，银行柜台报价一般是4位小数，但交易级数据源一般是6位。做监控系统，建议统一按6位小数处理，入库时保留原始精度，展示时按业务需要截断。

第三个坑是时区问题。API返回的日期时间通常都是UTC时间，而你要监控的“每日收盘价”如果按北京时间算，就是UTC+8的晚上。如果你拿UTC的日期去做“每日一次”的定时任务，可能出现日期错位的现象——北京时间已经是第二天了，API返回的还是前一天的快照。这块建议在程序里统一用UTC时间做调度逻辑，只在展示或者触发规则时换算成本地时区。

3. 核心代码实现：从拉取到监控告警的完整落地

3.1 基础拉取模块：请求汇率并解析响应

准备工作做完了，下面进入正题，写代码。我以Python为例，因为Python在这种小工具类项目里最顺手，requests库加APScheduler就能搞定，而且代码可读性好，方便你后续自己扩展。

第一步，实现一个基础的数据拉取模块。不管用哪家API，结构都是类似的，无非是请求URL、拼接参数、加Key、解析响应。

python复制import requests
import time
import json

class ForexClient:
    def __init__(self, api_key, base_url="https://api.example.com/v1"):
        self.api_key = api_key
        self.base_url = base_url
        self.session = requests.Session()
        # 统一设置超时，防止某个请求卡死拖垮整个监控流程
        self.session.timeout = 10

    def get_rates(self, base_currency="USD", target_currencies=None):
        """
        获取基础货币兑目标货币的汇率
        :param base_currency: 基础货币，比如 USD
        :param target_currencies: 目标货币列表，比如 ["CNY", "EUR", "JPY"]
        :return: dict，形如 {"CNY": 7.1234, "EUR": 0.8123}
        """
        if target_currencies is None:
            target_currencies = ["CNY", "EUR", "JPY"]
        
        params = {
            "app_id": self.api_key,
            "base": base_currency,
            "symbols": ",".join(target_currencies)
        }
        
        try:
            resp = self.session.get(f"{self.base_url}/latest.json", params=params)
            resp.raise_for_status()
            data = resp.json()
        except requests.exceptions.Timeout:
            print(f"[{time.strftime('%Y-%m-%d %H:%M:%S')}] 请求超时")
            return None
        except requests.exceptions.RequestException as e:
            print(f"[{time.strftime('%Y-%m-%d %H:%M:%S')}] 请求失败: {e}")
            return None
        
        # 不同API的响应结构略有不同，核心都是 rates 字段
        if "rates" not in data:
            print(f"[{time.strftime('%Y-%m-%d %H:%M:%S')}] 响应格式异常: {data}")
            return None
        
        return data["rates"]

这个模块很简单，但我有几个固定的习惯分享给你。

第一，用 requests.Session() 而不是每次直接 requests.get()。Session会复用底层的TCP连接，在频繁请求的场景下，能减少握手开销，速度快不少。我之前在循环里直接调 requests.get()，跑了一段时间发现平均每个请求要多了几十毫秒的耗时，改成Session之后明显改善。

第二，设置超时是必须的。网络请求不可控，万一API服务商那边卡了，你的监控进程不能傻等着。超时时间我一般设10秒，上限不超过15秒，否则定时任务会堆积。

第三，对响应做异常兜底。API返回的数据结构可能会变，或者因为参数错误返回错误信息，如果直接 data["rates"] 去取，KeyError会直接把程序打挂。我在代码里加了一层判断，异常情况打印日志并返回None，这样上层逻辑可以决定是重试还是跳过。

3.2 本地换算逻辑：没有直接报价的货币对怎么处理

准备好拉数据之后，你会遇到一个现实问题：并非所有货币对都有直接报价。比如你想监控“美元兑人民币”和“日元兑人民币”，但API只返回了USD/CNY、USD/JPY。你手里没有JPY/CNY的直接报价。

这时就要用到套算汇率（Cross Rate）计算。公式很简单：如果A/B有报价，B/C有报价，那么A/C的汇率就等于(A/B)乘以(B/C)。

举个例子。API返回USD/CNY = 7.1234，USD/JPY = 149.32。那你想要JPY/CNY，可以这样算：

JPY/CNY = (USD/CNY) / (USD/JPY) = 7.1234 / 149.32 ≈ 0.04771

意思就是1日元约等于0.04771人民币。

在程序里，我会把这个逻辑封装成一个换算模块，核心是先把所有拿到的报价统一成“单位基础货币兑目标货币”的格式，然后再做交叉换汇。

python复制def convert_rates(rates, base_currency="USD"):
    """
    将API返回的汇率换算成任意货币对。
    rates 是从API拿到的 dict，如 {"USD": 1.0, "CNY": 7.1234, "JPY": 149.32, "EUR": 0.9234}
    这里以USD为参考基准，换算成 "A->B" 的含义是 1单位A = 多少单位B
    """
    # 第一层：确保基准货币USD在rates里，且值为1.0
    # 如果不在，需要根据其他货币推算
    converted = {}
    for base in rates:
        for target in rates:
            # 通过USD做中间桥梁：1单位base = 多少单位USD = 1 / rates[base]
            # 多少单位USD = 多少单位target = rates[target]
            # 所以 1 base = rates[target] / rates[base] 个 target
            converted[f"{base}/{target}"] = rates[target] / rates[base]
    return converted

# 使用示例
rates = {"USD": 1.0, "CNY": 7.1234, "JPY": 149.32, "EUR": 0.9234}
all_pairs = convert_rates(rates)
print(all_pairs["JPY/CNY"])   # 0.047708...
print(all_pairs["EUR/CNY"])   # 7.7138...

这样，只要API返回的币种列表足够丰富，你就能算出任意货币对的价格。这个方法在业界叫“套算”，做外汇交易的朋友都很熟。

但是这里要注意精度问题。交叉换汇计算会放大误差，如果源数据的精度不够，算出来的结果可能偏差很大。比如你从免费API拿到的USD/JPY只有整数精度149，那算出来的JPY/CNY误差范围就很大。所以如果你的应用场景对精度有要求，源数据最好用6位小数精度的API，并且中间计算用Decimal而不是float。

如果你在乎精度，可以改用Python的decimal模块。不过我自己的经验是，绝大多数非交易场景用float就够了，因为银行公布的牌价本来也只有4位小数，你监控的是趋势和阈值，不是做市商报价。只有在做对冲计算或者盈亏核算时才需要更高的精度。

3.3 阈值监控与告警触发

数据拉回来了，换算也做完了，接下来就到了核心业务逻辑：判断汇率是否触及你设定的阈值，如果触及就告警。

我推荐的架构不是把阈值判断写死在主流程里，而是做成一个规则引擎。每条监控规则包含：货币对、方向（大于或小于）、阈值、告警文案、告警方式。把规则做成可配置的，你不需要改代码，只改配置文件就能调整监控策略。

下面是一个简单的实现思路。

python复制# 配置监控规则，实际使用中可以放到JSON或YAML文件里
monitor_rules = [
    {
        "pair": "USD/CNY",
        "operator": ">",       # 当汇率大于该值时告警
        "threshold": 7.2000,
        "message": "美元兑人民币突破7.2"
    },
    {
        "pair": "EUR/CNY",
        "operator": "<",
        "threshold": 7.5000,
        "message": "欧元兑人民币跌破7.5"
    },
    {
        "pair": "JPY/CNY",
        "operator": "<",
        "threshold": 0.0450,
        "message": "日元兑人民币跌破0.045"
    }
]

def check_thresholds(prices, rules):
    """
    检查所有规则，返回触发告警的信息列表
    :param prices: dict，形如 {"USD/CNY": 7.1234, "JPY/CNY": 0.0477}
    :param rules: 规则列表
    :return: 告警信息列表
    """
    alerts = []
    for rule in rules:
        pair = rule["pair"]
        if pair not in prices:
            # 当前数据源没有该货币对，跳过
            continue
        price = prices[pair]
        threshold = rule["threshold"]
        
        if rule["operator"] == ">" and price > threshold:
            alerts.append(f"[价格提醒] {rule['message']}，当前 {pair}={price:.4f}")
        elif rule["operator"] == "<" and price < threshold:
            alerts.append(f"[价格提醒] {rule['message']}，当前 {pair}={price:.4f}")
    return alerts

告警方式上，我推荐优先级从高到低是：企业微信/钉钉/飞书机器人Webhook、Telegram Bot（如果访问没问题的话）、邮件、本地日志。

实际项目中最常用的是飞书或企业微信的群机器人，申请一个Webhook地址，往里面POST一段JSON，消息就能推送到群里。这个方式配置简单，稳定，而且多人可见，适合团队协作场景。邮件告警虽然正式，但延迟高，容易进垃圾箱，适合做日报汇总而不是实时告警。

下面是一个往企业微信群机器人推消息的代码片段。

python复制import requests

def send_wecom_webhook(webhook_url, content):
    """发送文本消息到企业微信群"""
    headers = {"Content-Type": "application/json"}
    payload = {
        "msgtype": "text",
        "text": {
            "content": content,
            "mentioned_list": ["@all"]   # 或指定人
        }
    }
    try:
        resp = requests.post(webhook_url, json=payload, headers=headers, timeout=5)
        resp.raise_for_status()
        return True
    except Exception as e:
        print(f"发送企业微信消息失败: {e}")
        return False

这块有几个坑我得说一下。

第一个坑是告警风暴。如果汇率一直在阈值附近上下波动，你的机器人会疯狂刷屏。解决方法是加一个“冷却时间”——同一个规则触发后，至少间隔N分钟才能再次触发。我在实际项目中一般设置冷却时间为30分钟到1小时，避免对团队造成干扰。

第二个坑是精确比较时浮点误差带来的误报。比如你设置阈值是7.2，程序判断价格是否大于7.2，但浮点数运算时7.2可能在内存里是7.2000000001，或者7.1999999999。在边界值附近可能产生误报或漏报。稳妥的做法是引入一个小的epsilon偏差，或者在比较时统一用Decimal，保留4位小数再比较。

第三个坑是告警消息一定要带上时间戳和当前价格。接警的人看到一条消息，应该立刻能判断它的时效性。这个细节在关键时刻很能体现工程素养。

3.4 定时任务：让监控真正跑起来

如果你已经走到这一步，你可以手动运行一次脚本，拉取汇率、判断阈值、推送告警。但“监控”要20小时不停歇地跑，需要定时调度机制。

调度方案有两种做法：用APScheduler在Python代码内部定时执行任务；或者用系统级cron调用你的脚本。这两种我都用过，推荐一个简单可靠的组合：直接用cron，靠操作系统来拉起任务。

用cron的好处是：即使Python进程崩溃了，下一个cron周期还会重新拉起脚本，天然自带“进程守护”功能。相比之下，APScheduler如果主进程崩溃了，所有任务就都没了。

crontab配置可以参考下面这样：

bash复制# 每10分钟执行一次汇率监控脚本
*/10 * * * * /usr/bin/python3 /opt/forex-monitor/monitor.py >> /opt/forex-monitor/monitor.log 2>&1

# 每天北京时间 18:00 执行一次收盘汇总
0 18 * * * /usr/bin/python3 /opt/forex-monitor/daily_summary.py >> /opt/forex-monitor/daily.log 2>&1

注意cron默认用系统时区。如果你的服务器是UTC时区，而你想每天北京时间18点执行，需要把cron时间换算成UTC，也就是每天10:00执行。或者更简单，在cron行首加上时区声明。

如果你偏好用APScheduler，代码长这样：

python复制from apscheduler.schedulers.blocking import BlockingScheduler

def job():
    print("开始拉取汇率...")
    client = ForexClient(api_key="your_api_key")
    rates = client.get_rates(base_currency="USD", target_currencies=["CNY", "EUR", "JPY"])
    if not rates:
        return
    # 换算 + 阈值判断 + 告警
    # ...

if __name__ == "__main__":
    scheduler = BlockingScheduler()
    # 每10分钟执行一次
    scheduler.add_job(job, 'interval', minutes=10)
    # 每天 18:00 执行一次（使用北京时间）
    scheduler.add_job(daily_summary, 'cron', hour=18, minute=0, timezone='Asia/Shanghai')
    scheduler.start()

这里特别提醒一个鲜为人知的坑：APScheduler的cron触发器默认使用的时区是系统时区，如果你部署在一台UTC服务器上，hour=18 指的是UTC时间18点，不是北京时间。你必须显式传入 timezone='Asia/Shanghai' 参数，别问我怎么知道的，都是血泪教训。

4. 部署与日志：别让监控器自己先挂了

4.1 定时调度的两种姿势

上面提到了cron和APScheduler两种调度方式，我再从实际运维的角度多聊两句它们的适用场景。

如果你只有一台轻量云服务器，跑几个Python脚本，我建议老老实实用cron。原因很简单：cron是操作系统级别的，不依赖Python环境，你的代码崩溃了也无所谓，下一个周期照常拉起。而APScheduler的问题是，如果脚本里发生了未捕获的异常导致整个进程退出，所有定时任务就停了。要解决这个问题，你得自己额外写守护进程或者systemd service，复杂度上了一个台阶。

但如果你需要复杂的调度逻辑——比如任务之间有依赖、需要动态添加删除任务、或者需要在多个任务间共享状态——那APScheduler会更顺手。它提供了内存和持久化两种任务存储方式，可以让你在应用运行期间动态增删任务，灵活度高很多。

我的个人建议是：单机、单脚本，用cron；需要复杂任务编排，用APScheduler加systemd托管。两个方案我都在生产环境跑过，可靠性和维护成本高下立判。

4.2 日志与异常处理

监控系统运行过程中，最怕的不是“汇率没变化”，而是“脚本挂了但你不知道”。

我的做法是双保险：一方面把所有运行日志写入文件，另一方面在关键异常发生时通过告警渠道通知自己。

日志怎么写？用Python自带的logging模块就够了，不需要引入额外的库。但我建议配置成RotatingFileHandler——日志文件按大小滚动，避免单个日志文件无限增长把磁盘撑爆。

python复制import logging
from logging.handlers import RotatingFileHandler

logger = logging.getLogger("forex_monitor")
logger.setLevel(logging.INFO)

handler = RotatingFileHandler(
    "/opt/forex-monitor/monitor.log",
    maxBytes=10 * 1024 * 1024,  # 每个日志文件10MB
    backupCount=5               # 保留最近5个文件
)
formatter = logging.Formatter('%(asctime)s - %(levelname)s - %(message)s')
handler.setFormatter(formatter)
logger.addHandler(handler)

# 使用示例
logger.info("汇率拉取成功: USD/CNY=7.1234, EUR/CNY=7.7138")
logger.warning("API响应超时，本次跳过")
logger.error("解析汇率响应失败: %s", resp_text)

异常处理方面，我给自己定了一个准则：爬虫和交易类的脚本，永远不要在顶层暴露未捕获的异常。把所有可能出错的操作放在try-except里，出错时记录日志并返回安全的默认值，而不是让整个进程崩掉。

python复制def main():
    try:
        client = ForexClient(api_key=API_KEY)
        rates = client.get_rates()
        if not rates:
            logger.warning("获取汇率为空，跳过本次监控")
            return
        
        all_pairs = convert_rates(rates)
        alerts = check_thresholds(all_pairs, monitor_rules)
        
        if alerts:
            for alert in alerts:
                logger.info("告警触发: %s", alert)
                send_wecom_webhook(WEBHOOK_URL, alert)
        else:
            logger.info("所有汇率正常，未触发告警")
            
    except Exception as e:
        logger.error("监控任务异常: %s", e, exc_info=True)
        # 如果整个流程异常，主动发一条告警通知
        send_wecom_webhook(WEBHOOK_URL, f"[监控异常] 任务执行失败: {e}")

if __name__ == "__main__":
    main()

4.3 部署环境注意事项

关于部署环境，几条经验供参考。

用一台最低配的云主机就够跑了，这类监控任务负载很低，内存占用一般不超过100MB。我甚至用一台1核512MB的“老古董”跑过一年多的监控脚本，非常稳定。但千万别部署在本机或者公司内网，尤其是需要7x24小时接收告警的场景——本机断电、断网、休眠，都会让监控消失于无形。

部署时建议使用虚拟环境，避免把依赖装到系统Python里，污染全局环境。用venv或者conda都行。

bash复制cd /opt/forex-monitor
python3 -m venv venv
source venv/bin/activate
pip install requests apscheduler

另外，如果你用API Key直接写到代码里，记得注意安全。个人使用问题不大，但如果代码要提交到Git仓库，建议用环境变量或者单独的配置文件承载密钥，同时把配置文件加入.gitignore。

bash复制# .env 文件示例
export FOREX_API_KEY="xxxx-xxxx-xxxx"
export WECOM_WEBHOOK_URL="https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxxx"

然后在Python里读环境变量：

python复制import os

API_KEY = os.getenv("FOREX_API_KEY")
WEBHOOK_URL = os.getenv("WECOM_WEBHOOK_URL")

5. 常见问题与排查技巧实录

5.1 典型问题速查表

我把实际运行中遇到的高频问题整理成一张表，方便你对照排查。

5.2 排查案例：免费API突然返回502

有次我的监控脚本突然连续拉取失败，日志里全是HTTP 502。一开始怀疑是我的服务器网络问题，在服务器上curl测试了API地址，发现响应正常，但速度明显变慢。

后来排查发现是免费套餐的公共端点因为高峰期资源不足导致不稳定，而付费专属端点没有这个问题。我的处理方案是换了一家用国内CDN节点的API服务商，尽管免费额度少一些，但稳定性明显提升。

这个案例给我的启发是：免费API的稳定性参差不齐，特别是在关键业务场景下，别把宝全押在一家免费服务上。可以配置主备两个数据源，主数据源挂了自动切换备用的，这样即使一家服务商出问题，你的监控系统仍然能继续工作。

5.3 调试技巧：没有真实API怎么测逻辑

如果你还没有申请到API Key，或者不想在开发阶段消耗配额，我有几个办法帮你离线调试。

最简单的方法是mock数据。我自己封装了一个调试模式，当环境变量 DEBUG=1 时，请求函数不会真正访问网络，而是返回内置的一组模拟数据。这样所有下游逻辑、阈值判断、告警推送都能完整跑通，不费一分钱API额度。

python复制DEBUG = os.getenv("DEBUG", "0") == "1"

MOCK_RATES = {
    "USD": 1.0,
    "CNY": 7.1234,
    "EUR": 0.9234,
    "JPY": 149.32,
    "GBP": 0.7834,
}

def get_rates(base_currency="USD", target_currencies=None):
    if DEBUG:
        return {k: v for k, v in MOCK_RATES.items() if k in target_currencies}
    # 真实请求逻辑...

另外，建议用 curl 先手动测试API返回结构，再写代码解析。这样可以避免你对着一个错误的字段名傻排查半天。

还有一个技巧：把每次拉到的原始响应存一份快照到本地。这样即使后面程序出了bug，你可以回溯历史数据，判断是“数据源问题”还是“程序逻辑问题”。

5.4 数据校验与异常过滤

前面提过数据校验，这块值得单独展开讲讲。

外汇汇率有它自身的规律：正常情况下，USD/CNY会在6.0到8.0区间波动，USD/JPY会在100到160区间波动。如果某次拉到的数据跳出了这个合理区间，基本可以断定是数据源异常或解析错误，直接丢弃比盲目存储更安全。

我的做法是维护一个合理区间表，每次拉回数据先做一次基础校验：

python复制# 正常波动区间，实际可以按历史数据动态计算
VALID_RANGES = {
    "USD/CNY": (6.0, 8.0),
    "USD/JPY": (100.0, 160.0),
    "EUR/CNY": (7.0, 8.5),
    "JPY/CNY": (0.03, 0.06),
}

def is_valid_price(pair, price):
    if pair not in VALID_RANGES:
        return True  # 没有配置的货币对，不校验
    low, high = VALID_RANGES[pair]
    return low <= price <= high

这种简单的区间校验是我强烈建议加上的，它成本极低，但能挡住大部分数据异常。放在数据入库之前，比入库后再清洗要靠谱得多。

最后再分享一个小技巧

整个系统跑起来之后，我建议你把自己也当成一个被监控的客户。给每条告警设置合理的冷却时间，告警文案要包含货币对名称、当前价格、触发时间和建议动作，让接警的人一眼看明白该干嘛。

如果这个系统后续要扩展，可以考虑把历史数据存到SQLite或PostgreSQL里，积累一段时间后就能做趋势统计分析——比如算出一周内USD/CNY的最高价、最低价、平均值，为你的报价决策提供参考。数据积累得越多，这个工具的价值越大。

我在实际使用中还有一个习惯：每当汇率发生剧烈波动，我不只看当次告警，还会把前后几次拉取的价格拉出来对比，确认这是一次真实的波动还是数据源抖动。把这个对比逻辑做成一个简单的函数，对判断市场情绪特别有帮助。这些小工具串联起来，一个完整的汇率监控系统就成型了。