IP 访问限制选型指南（含实现示例与存储策略）
当我们要限制后端服务的访问来源 IP，常见落点有四层：云/边缘、操作系统/网络层、反向代理（Nginx 等）、应用层（Flask 中间件）。不同位置各有优劣，实际工程里经常组合使用：外层做大过滤，应用层做精细规则与审计。
1. 放在哪里限制？
应用层（Flask 中间件）
- 优点：逻辑灵活（按路由、账号、时间窗）、易审计、可热更新。
- 缺点：到达应用才拦截，占用应用算力；极端并发下瓶颈更早暴露。
- 场景：需要细粒度策略、灰度/审计、与业务状态码统一返回。
反向代理/Nginx
- 优点：高性能、配置简单、支持引用外部列表文件、热加载快。
- 缺点：策略表达力一般；更复杂的动态策略需脚本/模块配合。
- 场景：绝大多数生产入口；承接万级规则无压力。
操作系统/网络层（iptables/nftables + ipset、Windows 防火墙）
- 优点：性能最佳，百万级也可；到达服务前即丢包。
- 缺点：可运维性一般、审计/联动弱。
- 场景：硬性安全边界、海量规则、抗 DDoS 前置。
云/边缘（安全组/WAF/CDN）
- 优点：即开即用、全球边缘清洗；可配国别/ASN/机器人规则。
- 缺点：有成本；极细规则需要付费/自定义。
- 场景：公网服务、需要边缘防护/速率限制/Bot 管理。
2. 规则存储怎么选？
环境变量/.env
- 优点：零依赖、上手最快。
- 缺点：不适合大量规则、发布才更新。
- 适用：少量静态规则、开发/测试。
文本文件列表（
allow.list/deny.list）- 优点：比 .env 更好维护，可做热更新（定时 reload）。
- 缺点：缺审计/权限管理；多实例一致性要自己做。
- 适用：中小规模、无后台管理需求。
数据库（关系型，如 MySQL）
- 优点：强一致、可审计、易做后台管理、易做到期/备注。
- 缺点：查询要做缓存或预加载，否则每请求查库会拖慢。
- 适用：企业项目首选；规则多、需要在线维护/审计。
Redis（内存存储/缓存）
- 优点：读写快、支持集合操作、易做热更新与 pub/sub 通知。
- 缺点：纯 Redis 作为“唯一存储”需考虑持久化与数据安全。
- 适用：与 MySQL 搭配做缓存；或纯内网场景追求极致速度。
结论：不是“只能 Redis”。建议“数据库（MySQL）作为权威存储 + Redis 作为缓存/加速”，或在规模较小的情况下仅用文件/配置即可。
3. 参考数据模型与加载策略
- MySQL 表设计（白/黑名单 + 网段/CIDR + 到期时间）
CREATE TABLE ip_rule (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
rule_type ENUM('allow','deny') NOT NULL,
cidr VARCHAR(64) NOT NULL, -- 支持单 IP（当作 /32 或 /128）或 CIDR
enabled TINYINT(1) NOT NULL DEFAULT 1,
priority INT NOT NULL DEFAULT 100, -- 可选：更细优先级
expires_at DATETIME NULL,
note VARCHAR(