std::isascii配合std::all_of可安全判断字符串是否全为ASCII字符，需将char转为unsigned char避免未定义行为；手动循环检查0~127范围更轻量。
用 std::isascii 配合 std::all_of 最直接
标准库提供了 std::isascii（定义在 <cctype> 中），它接受 int 参数，对每个 char 做安全的 ASCII 判断（注意：传入前必须先转为 unsigned char，否则负值 char 会触发未定义行为）。配合 std::all_of 可简洁实现全字符检查：
#include <string>
#include <algorithm>
#include <cctype>
bool is_all_ascii(const std::string& s) {
return std::all_of(s.begin(), s.end(), [](unsigned char c) {
return std::isascii(c);
});
}
这个写法清晰、可读性强，且能正确处理 char 在平台上有符号（signed）的情况。别直接传 char 给 std::isascii——比如在 Linux x86_64 上，'\xFF' 作为 char 是 -1，传进去就 UB。
手动遍历 + 范围判断更轻量、无依赖
如果不想引入 <algorithm> 或担心 lambda 开销（极少数场景），直接用循环判断 0 更底层也更可控：
bool is_all_ascii(const std::string& s) {
for (unsigned char c : s) {
if (c > 127) return false;
}
return true;
}
关键点在于用 unsigned char 遍历——这能确保所有字节都被解释为 0–255 范围内的值，避免符号扩展干扰。用 signed char 或裸 char 循环时，遇到高位为 1 的字节（如 UTF-8 中文字符的首字节 0xE4）会被当成负数，比较逻辑就乱了。
立即学习“C++免费学习笔记（深入）”；
注意 std::string 的编码假设和实际内容不一致的风险
std::string 本身不携带编码信息，它只是字节容器。你调用 is_all_ascii 检查的是一串字节是否都落在 0–127，但这些字节可能本意是 UTF-8 编码的一部分（比如 "café" 中的 é 是两个字节 0xC3 0xA9，每个字节都 >127，会被判为非 ASCII；而纯英文字符串 "cafe" 四个字节全
- 如果你的字符串本应是 UTF-8，但混入了非法字节序列（如孤立的
0xC0），这个函数仍会返回false—— 这其实是合理的，因为那根本不是有效 UTF-8，更不是 ASCII - 如果你从文件或网络读入数据，且未明确指定编码，
is_all_ascii返回true只说明“看起来像 ASCII”，不代表内容语义上就是 ASCII 文本（比如它可能是被错误解码的 GBK 字节流）
不要用 std::isalnum 等分类函数替代
std::isalnum、std::isprint 等 C 风格字符函数依赖当前 C locale，而默认 locale 下它们的行为不可靠：
- 在某些系统上，
std::isprint('\x80')可能返回 true（如果 locale 支持 Latin-1） - 它们不区分 ASCII 和扩展 ASCII，只要在当前 locale 下被视作“可打印”就过，完全偏离“是否为 0–127”的原始需求
- 调用前同样要强转
unsigned char，否则负值参数导致未定义行为
所以这类函数不能用于严格 ASCII 检测，仅适用于 locale-aware 的文本处理场景。
真正容易被忽略的是字符类型转换时机：哪怕只漏掉一次 unsigned char 强转，在调试时可能表现正常（因为测试数据全是 a-z），上线后遇到带高字节的数据就崩溃或误判。宁可多写一个 cast，别信编译器帮你静默补零。
