不能直接用$_SERVER['REMOTE_ADDR']做地理定位，因为经Nginx、CDN或负载均衡后该值仅为代理出口地址（如127.0.0.1），查库将定位到机房而非用户真实位置；必须通过Nginx set_real_ip_from与real_ip_header配合，并在PHP层安全解析X-Forwarded-For或X-Real-IP获取真实IP。
为什么不能直接用 $_SERVER['REMOTE_ADDR'] 做地理定位
因为真实客户端 IP 在经过 Nginx、CDN 或负载均衡后，$_SERVER['REMOTE_ADDR'] 只会是代理出口地址（比如 127.0.0.1 或内网 IP），直接拿它查库或调 API 必然定位到机房位置，而不是用户所在地。
必须穿透代理链取真实 IP：
- Nginx 配置需含
set_real_ip_from 10.0.0.0/8（填你实际可控的代理网段），并设real_ip_header X-Forwarded-For - PHP 层优先读
$request->header('x-real-ip')；若无，则解析$request->header('x-forwarded-for')，取最左非私有地址（过滤127.0.0.0/8、10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、::1）
用什么方式查 IP 归属地才够快
高频请求下，HTTP 调第三方 API（如淘宝、IP138）会拖慢响应、受限流、不可靠。真正能扛住并发的只有本地化方案：
- 用纯真 IP 库（
qqwry.dat）+ PHP 扩展ip2region或php-qqwry：毫秒级查表，无网络依赖，适合 Webman 常驻内存模型 - 若需更细粒度（省市区、运营商），可预加载 MaxMind GeoLite2 的
.mmdb文件，配合maxmind-db/reader扩展，比 HTTP API 快 10 倍以上 - 避免在中间件里每次 new 一个解析器实例——Webman 复用协程，应把解析器作为单例注入或静态属性缓存
如何避免地理解析拖慢主流程
IP 地理位置不是核心业务逻辑，但又常被用于审计、风控、AB 测试等场景。同步阻塞查库会拉长 TTFB，尤其在高并发下明显。
Webman 2.2.0
下载
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
推荐两种轻量异步策略：
- 用
Worker::$processPool提交异步任务：把 IP 和请求上下文（如 route、user_id）打包丢给子进程查，结果写 Redis 或日志队列，不阻塞响应 - 更简单做法：只在
process()开头记录原始 IP 和时间戳，后续用离线脚本批量补全地理信息（比如每 5 分钟跑一次，查完写回 DB） - 切忌在
__construct()里初始化大文件或连接——GeoLite2.mmdb加载本身就要几 MB 内存，放错位置会撑爆 worker 内存
注意 geo 数据的精度与更新频率
纯真库和 GeoLite2 都不是实时数据，城市级精度尚可，但小区、街道级基本不准；且 IP 段分配变更频繁，老库半年不用就偏差明显。
关键点：
- 纯真库建议每月手动更新
qqwry.dat，Webman 启动时校验文件修改时间，自动 reload 解析器 - GeoLite2 免费版需每月底下载新
.mmdb，可用curl -o /path/to/GeoLite2-City.mmdb https://github.com/P3TERX/GeoLite.mmdb/raw/download/GeoLite2-City.mmdb自动化 - 不要把“北京”“上海”这类结果当绝对事实——移动网络出口 IP 经常集中于省会，实际用户可能在地级市甚至县城
