经纬度有效性需用std::stod转换后校验范围：纬度∈[-90.0,90.0]，经度∈[-180.0,180.0]；须捕获异常、去首尾空格、拒绝非数字字符及"0x"等非法前缀，并区分角色封装校验函数。
用 std::stod + 范围校验判断经纬度数值有效性
单纯匹配正则或分割小数点无法保证是合法经纬度——比如 "999.123" 或 "-185.0" 语法对但语义错。必须先转成浮点数，再检查数值范围。
关键逻辑：纬度必须在 [-90.0, 90.0]，经度必须在 [-180.0, 180.0]。注意边界值（如 90.0、-180.0）是合法的。
实操建议：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 用
std::stod转换，捕获std::invalid_argument（非数字）和std::out_of_range（溢出，如超长科学计数） - 转换后立刻检查范围，别等后续计算再报错
- 允许前导空格和尾随空格，但中间不能有空格（
"40.7128, -74.0060"是两个坐标，不是单个经纬度字符串） - 不建议用
atof：它对错误不抛异常，失败时静默返回0.0，容易误判"abc"为有效纬度
处理常见非法输入：空串、多余符号、单位文本
用户粘贴的字符串常带干扰信息，比如 "lat: 31.2304°N"、"23.1234567890123456789"（精度远超 double 表示能力）、"23.12, 113.23"（逗号分隔，应视为坐标对而非单值）。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 用
std::string::find_first_not_of(" \t\n\r")和find_last_not_of去首尾空白，再判断是否为空 - 检查是否含字母、中文、度符号（
°）、方向字母（N/S/E/W）——这些需额外解析逻辑，不属于“纯经纬度格式” - 若含逗号或分号，直接拒绝：这不是单个经纬度，而是坐标对或带分隔符的字符串
- 极长小数（如 >17 位小数）不必然非法，但
std::stod会截断；只要截断后仍在范围内，仍算有效
区分“纬度字符串”和“经度字符串”的校验逻辑
同一套解析代码不能混用：纬度上限是 90.0，经度是 180.0。如果业务中传入的是明确角色的字符串（如配置项 "latitude" 或 "longitude"），校验必须严格按角色走。
实操建议：
- 封装两个函数：
is_valid_latitude(const std::string& s)和is_valid_longitude(const std::string& s)，避免参数传错 - 不要依赖字符串内容判断角色（比如看到
"120"就当经度）——"120"作为纬度是非法的，但仅靠值无法反推原意 - 若输入是
"39.9042 N"这类带方向的，需先归一化：N/E 视为正，S/W 视为负，再统一走数值校验
注意浮点解析的隐式行为：+/- 号、进制、下划线
std::stod 支持前导 +、-，也支持 C++14 的数字字面量下划线（如 "12_3.45"），但实际输入几乎不会出现下划线。更现实的风险是八进制误解析。
实操建议：
-
std::stod默认按十进制解析，不会把"0123.45"当八进制——这点放心 - 但要警惕以
"0x"开头的字符串：std::stod("0x1p3")会成功解析为8.0（符合 IEEE 754 hexfloat），这在经纬度场景属于非法输入，应提前用find("0x") != std::string::npos拦截 - 允许
"+.5"、"-.5"，这是标准行为，无需特殊处理 - 不接受逗号千位分隔符（
"1,234.56"），std::stod遇到第一个非数字字符就停，结果是1.0，必须提前过滤
真正难的不是解析，是定义清楚“谁负责清理输入”。前端传来的字符串如果已经带单位或空格，C++ 层该拒绝还是该尽力修复？多数健壮服务会选择“严格校验 + 明确报错”，把清洗逻辑留给上游——毕竟 "23.123°N" 看似友好，但一旦解析规则微调，就可能漏掉边界 case。
