应优先使用libcurl 7.62.0+的curl_url API进行RFC 3986合规解析，调用curl_url_init()和curl_url_set()校验，返回CURLUE_OK即合法；若无法引入依赖，可复用std::regex预编译正则做基础格式过滤。
用 std::regex 做基础 URL 格式校验（C++11 起可用）
标准 C++ 没有内置的 URL 解析器，std::regex 是最直接、可控的轻量级方案。它不验证域名是否真实存在、协议是否支持，但能可靠识别常见 URL 结构是否合法。
注意：正则不能替代完整解析，仅用于「字符串看起来像不像 URL」的快速过滤。
- 推荐用 RFC 3986 的简化正则：
^([a-zA-Z][a-zA-Z0-9+.-]*):\/\/([^\s\/]+)(\/[^\s]*)?$ -
std::regex默认使用 ECMAScript 语法，需转义反斜杠 —— 实际写成"^([a-zA-Z][a-zA-Z0-9+.-]*):\/\/([^\\s\/]+)(\/[^\\s]*)?$" - 匹配成功只说明「有协议头 + 双斜杠 + 主机部分」，不保证端口、路径编码、查询参数格式正确
- 性能敏感场景慎用：每次构造
std::regex对象开销不小，应复用已编译的std::regex实例
static const std::regex url_pattern(R"(^([a-zA-Z][a-zA-Z0-9+.-]*)://([^\s\/]+)(\/[^\s]*)?$)");
bool is_url_like(const std::string& s) {
return std::regex_match(s, url_pattern);
}用 libcurl 的 curl_url API 做严格解析（C++17+ 推荐）
如果你已依赖 libcurl（比如项目里本来就在发 HTTP 请求），它的 curl_url 系列函数是目前 C++ 生态中最接近「真正判断 URL 是否规范」的方案 —— 它会尝试解析并拆解 scheme、host、port、path 等字段，失败即说明格式非法。
- 需要 libcurl ≥ 7.62.0，且编译时启用
CURL_DISABLE_PARSEQT外的默认选项 - 调用
curl_url_get()获取各部件时返回CURLE_URL_MALFORMAT就是明确的「不符合 URL 规范」信号 - 比正则更准：能识别
https://[::1]:8080/path（IPv6 字面量）、带用户信息的ftp://user:pass@example.com等边缘情况 - 不抛异常，需检查返回值；解析后记得调用
curl_url_cleanup()防内存泄漏
CURLU* h = curl_url(); CURLUcode rc = curl_url_set(h, CURLUPART_URL, s.c_str(), 0); bool valid = (rc == CURLUE_OK); curl_url_cleanup(h);
为什么不用 std::filesystem::path 判断？
std::filesystem::path 是为本地文件路径设计的，它把 http://example.com 当作一个带冒号的普通文件名（root_name() 返回 "http:"），完全不理解 URL 协议语义。
立即学习“C++免费学习笔记（深入）”；
- 调用
.is_absolute()对 URL 返回false（因为没识别出协议头） -
.has_filename()或.extension()在 URL 上行为无意义，比如把?q=a&b=2当作扩展名 - 误用会导致逻辑错乱，尤其在路径拼接或规范化场景下
Windows 上要注意的路径混淆点
Windows 用户常把 C:\foo\bar 或 \server\share 误认为 URL，其实它们是本地路径或 UNC 路径，不是 URL —— 即使加了 file:// 前缀也必须严格遵循 URL 编码规则（空格要变 %20，反斜杠要统一为正斜杠）。
-
file:///C:/foo/bar✅（三个斜杠，正斜杠，无空格） -
file://C: ooar❌（反斜杠未转义，协议后少一个/） -
file://localhost/c:/foo bar❌（空格未编码） - UNC 路径转 URL 必须变成
file://server/share/path，开头双斜杠不是三个
真正难的不是写对正则或调对 API，而是想清楚你要拦住什么：是防止用户输错粘贴？还是做服务端输入过滤？前者宽松一点没问题，后者必须用 libcurl 或专业库（如 cpp-httplib 内置解析器）逐字段校验。
