不能直接写 s[i] += shift，因为ascii字母不连续闭合，加减会越界产生非法字符，且std::isalpha等函数在负char时可能崩溃，须转unsigned char判断；caesar_encrypt中加26再%26是为了确保余数在0–25范围内。
为什么不能直接写 s[i] += shift
因为 ASCII 字母不是连续闭合的：'Z'（90）加 1 得到 '['（91），跳过了所有小写字母；'z'（122）加 1 得到 '{'（123）。C++ 不做字母表循环，也不会自动区分大小写。直接加减会破坏字符类型，甚至产生控制符或非法打印字符。
更危险的是，std::isalpha 等函数在传入负值 char 时可能崩溃（glibc 下常见），必须先转成 unsigned char 再判断。
- 小写字母范围是
'a'到'z'（97–122），大写是'A'到'Z'（65–90） - 空格、数字、标点等非字母字符必须原样保留，不能参与位移
- 移位前必须用
std::isalpha(static_cast<unsigned char>(c))</unsigned>安全判断
caesar_encrypt 函数里为什么要加 +26 再 %26
C++ 中负数取模结果依赖实现：-5 % 26 在某些编译器下是 -5，不是 21。而我们需要始终得到 0–25 范围内的余数。
加 + 26 是为了确保被模数为正——哪怕 shift 是 -100，(c - 'a' + shift + 26) 仍可能为负，所以更稳妥的做法是先归一化 shift %= 26，再统一加 26：
int normalized_shift = shift % 26; if (normalized_shift <p>然后代入：<code>'a' + (c - 'a' + normalized_shift) % 26</code>。这样既避免重复加法，又消除负模歧义。</p><div class="aritcle_card flexRow artxards"> <div class="artcardd flexRow"> <a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill4025" title="C++ 算法竞赛自动化测试数据生成与校验框架"><img src="https://img.php.cn/upload/skill/000/000/081/178988956499722.jpg" alt="C++ 算法竞赛自动化测试数据生成与校验框架" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a> <div class="aritcle_card_info flexColumn"> <a rel="nofollow" href="/xiazai/skill4025" title="C++ 算法竞赛自动化测试数据生成与校验框架" class="overflowclass">C++ 算法竞赛自动化测试数据生成与校验框架</a> <p class="overflowclass">根据原题生成新题面、验证器及完整测试数据，自动套用 testlib 模板，用于用户要求生成测试数据时。</p> </div> <a rel="nofollow" href="/xiazai/skill4025" title="C++ 算法竞赛自动化测试数据生成与校验框架" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a> </div> </div><h3>加密和解密能不能共用一个函数</h3><p>能，而且强烈建议共用。解密不是“逆操作”，而是反向位移：加密用 <code>caesar_encrypt(s, 3)</code>，解密就用 <code>caesar_encrypt(s, -3)</code>——前提是你的模运算逻辑已处理负数（即含 <code>+ 26</code> 或已归一化）。</p>
- 不要另写
caesar_decrypt，两套逻辑极易不一致（比如一处忘了unsigned char转换） - 如果用户输入移位值为 100，
shift %= 26后变成 22，加密解密都按 22 处理，结果才可逆 - 传
-shift时仍需走同一套归一化流程，否则-100 % 26在不同平台行为不一致
中文、emoji 或 UTF-8 字符会出什么问题
std::string 是字节数组，凯撒算法逐字节操作。UTF-8 中文通常占 3 字节（如 “中” 是 \xe4\xb8\xad），对每个字节单独加 shift 会导致编码损坏，输出乱码甚至程序崩溃（如触发非法 UTF-8 序列）。
这不是 bug，是设计边界：凯撒密码只定义在单字节字母表上。实际使用时：
- 若输入含非 ASCII 字符，
std::isalpha返回 false，该字节会被跳过——但后续c - 'a'对\xe4这类值做运算无意义 - 生产环境应加检查：
for (unsigned char b : s) if (b > 127) { /* 拒绝或报错 */ } - 真要支持 Unicode，得用
std::wstring+ ICU 或手动解析 UTF-8，这已超出凯撒范畴
最常被忽略的，是把测试用的英文字符串换成中文后程序没报错，却静默产出无效密文——因为没做 ASCII 校验，也没意识到 char 的符号性陷阱。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
