c++oding="utf-8" ?>
直接用 std::string::find("://") 定位协议头，取 substr(0, pos) 即可；必须避免误用 find_first_of("://")，需检查 npos 并处理无协议 url（如 // 开头），协议名大小写敏感且允许 +、.、-。
用 std::string::find 定位 :// 分隔符最直接
协议头（如 http、https、ftp）一定出现在第一个 :// 之前，且不包含空格或斜杠。用 std::string::find 找到 :// 的位置，再用 substr(0, pos) 截取即可，无需正则或状态机。
常见错误是误用 find_first_of("://")——它会把 :、/、/ 当作独立字符匹配，导致在 https://example.com/path?x=y 中提前匹配到冒号，返回错误的 https 前缀 http。
- 必须用
find("://")，不是find_first_of - 要检查返回值是否为
std::string::npos，避免越界截取 - 协议名只取
://左侧，不包含后续空格或换行（URL 字符串应已 trim 过）
std::string url = "https://example.com";
size_t pos = url.find("://");
std::string scheme = (pos != std::string::npos) ? url.substr(0, pos) : "";
处理带用户信息或端口的 URL 时协议头不变
像 https://user:pass@example.com:8080/path 或 ftp://foo@bar.com 这类 URL，协议头仍是 https 或 ftp，:// 仍是最稳定锚点。中间的 @、:、/ 都不影响协议提取逻辑。
有人试图用 find_first_of(":/") 或拆分 / 来“更健壮”，反而会把 https 错判成 https（正确）但把 file 协议（如 file:///path）错切成 file（实际也对），可读性却下降，还引入边界 case。
-
file:///home/user→file（find("://")返回 4，截取0~4得file） -
git+ssh://user@host/repo→git+ssh（合法协议名，RFC 3986 允许+和.） - 空字符串或无
://的输入（如example.com）应返回空std::string
性能与兼容性：不用 std::regex，尤其在嵌入式或高频场景
std::regex 构造开销大，匹配慢，且 MSVC 和 libstdc++ 对 std::regex 的实现长期存在 bug（比如某些版本无法正确编译 ^([a-zA-Z][a-zA-Z0-9+.-]*)://）。而 find("://") 是 O(n) 单次扫描，内联友好，所有标准库都稳定支持。
- Clang、GCC、MSVC 下行为一致，无 ABI 差异
- 如果 URL 来自不可信输入，先做基础校验（如长度上限、不含控制字符），但协议提取本身不需额外过滤
- 若后续还需解析 host/port/path，建议用成熟解析器（如 cpr、uri-parser），但仅提协议头，没必要
注意 URL 编码和大小写：协议名通常小写但不强制
RFC 3986 规定协议名大小写不敏感（HTTP:// 和 http:// 等价），但实际提取时应原样保留。多数客户端生成的 URL 是小写，但不能假设输入一定小写。
如果你需要标准化协议名（例如统一转小写用于比较），那是后续步骤，和提取动作无关。强行在提取时 transform 会增加开销，且掩盖原始格式信息。
- 提取结果是
HTTPS就保留HTTPS，不要自动转成https - 协议名中允许字母、数字、
+、.、-（RFC 3986 §3.1），find("://")不影响这些字符的完整性 - 真正容易被忽略的是：有些 URL 以
//开头（如//cdn.example.com/script.js），此时无协议头，find("://")返回npos，必须处理该分支
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
