用 std::regex 做基础 URL 格式校验应使用 std::regex_match 配合模式 R"(^https?://[^\s/$.?#][^\s]*)"，仅作语法初筛；需前置清洗空白与控制字符，不支持 Unicode 主机名或完整 RFC 解析，生产环境应改用 Boost.URL 等专用库。
用 std::regex 做基础 URL 格式校验（C++11+）
标准 C++ 没有内置 URL 解析器，最直接的方式是用正则表达式匹配常见 URL 结构。但要注意：正则只能做**语法初筛**，不能替代完整解析。
一个实用的轻量级模式：
^https?://[^\s/$.?#].[^\s]*$
说明：
• ^https?:// 匹配 http:// 或 https://（不支持 ftp:// 等需自行扩展）
• [^\s/$.?#] 确保域名开头不是空格、/、$、.、?、#
• [^\s]*$ 允许路径、查询参数等，但拒绝含空白符的字符串
实操建议：
• 用 std::regex_match(str, pattern) 判断是否**完全匹配**（别用 regex_search）
• 在 Windows 上注意路径分隔符反斜杠 \ 不会误触发匹配——因为该正则要求开头必须是 http:// 或 https://
• 若字符串含中文或 Unicode 主机名（如 https://例子.com），此正则会失败；需先 Punycode 转换或改用更宽松模式
立即学习“C++免费学习笔记（深入）”；
为什么 std::filesystem::path 不能用于判断 URL
std::filesystem::path 是为本地文件路径设计的，它把 https://example.com/path 当作一个带冒号和斜杠的普通文件名处理，不会报错，也不会识别协议。
常见错误现象：
• std::filesystem::path("https://a.b/c").is_absolute() 返回 false（因它只认 C:\ 或 /）
• .extension() 可能返回 ".com/c"，完全失真
• 对 file:///home/user 这类合法 URL，它会当成相对路径解析
所以：
• 不要用 std::filesystem 做 URL 判定
• 更不要用 std::filesystem::exists() 去“验证” URL 是否可达——那是在查本地文件
需要真正解析时，绕不开第三方库
如果要提取协议、主机、端口、路径、查询参数，或者支持 mailto:、data:、IPv6 主机（[::1]）、带用户信息（user:pass@host）等场景，手写正则很快失控。
推荐方案：
• 轻量：用 uri 库（header-only，GitHub 搜索 “cpp-uriparser” 或 “uriparser”）
• 生产环境：用 Boost.URL（C++23 标准化前的事实标准，支持解析、构建、编码/解码）
• 注意：libcurl 的 curl_url 系列函数虽强，但 C 接口 + 需链接，适合已有 curl 依赖的项目
示例（Boost.URL）：boost::urls::result<boost::urls::url> u = boost::urls::parse_uri("https://user:pass@example.com:8080/path?q=1#frag");
若 u.has_value() 为 true，说明语法合法且可解析
容易被忽略的边界情况
真实 URL 字符串常混入用户输入、日志截断、粘贴错误，这些点极易漏判：
• 开头或结尾含不可见字符（如 \u200b 零宽空格）→ 正则匹配失败，但肉眼看不出
• 多余空格：" https://example.com " → 必须先 str.erase(0, str.find_first_not_of(" \t\n\r")); str.erase(str.find_last_not_of(" \t\n\r") + 1);
• 编码问题：URL 中的 %20 合法，但 %2G 非法；纯正则难校验百分号编码有效性
• 协议后双斜杠缺失：http:/example.com 或 http:///example.com —— 前者应拒，后者某些浏览器容错但规范不允许
结论：格式校验只是第一道过滤，后续仍需在发起网络请求前做异常捕获，不能全信字符串“看起来像 URL”
