chr函数要求参数i为0–1114111内的整数，取余构造时须确保结果在此范围，并防范负数、溢出及控制字符等边界风险。
取余配合 chr 做编码时，边界值测试的核心不是“随便加减几个数”，而是紧扣两个关键点：一是 chr 的合法输入范围（0–1114111），二是取余运算引入的数学边界与字符映射逻辑的交叠。一旦忽略这两层约束，生成的测试用例可能直接抛 ValueError，或者映射到控制字符、代理对、未分配码位等非预期区域。
明确 chr 的合法输入边界
chr(i) 要求 i 是 0 到 1114111（即 0x10FFFF）之间的整数。超出即报错。因此，任何基于取余构造的 i，都必须确保结果落在该区间内。
- 若用
i % N构造参数，N 必须 ≤ 1114112，否则余数可能合法但原始值溢出（比如(1114112 + 1) % 1114112 == 1，看似安全，但若中间步骤保留了大数参与计算，就可能触发异常） - 典型错误：用
ord(c) % 256后直接喂给chr—— 这只能覆盖 ASCII 范围，漏掉所有中文、emoji 等；更危险的是，若c是代理对首尾字符（如 U+D800），ord会失败，根本走不到取余这步 - 建议在测试中显式覆盖：
0、1、127（ASCII 上界）、128、2047、65535、65536、1114110、1114111这些关键分段点
关注取余导致的“折叠边界”
取余本质是周期性映射。例如用 i % 26 映射到小写字母，看似只有 0–25，但若 i 来自用户输入或外部数据，就可能出现负数、极大数、或跨 Unicode 块的值。
- 负数取余行为因语言而异：Python 中
-1 % 26 == 25，但其他环境（如 C 或某些数据库）可能返回 -1 → 喂给chr(-1)直接崩溃 - 测试必须包含负余数场景：构造
i = -1、-26、-27，观察取余后是否被正确归一化，再传入chr - 大数溢出风险：如
i = 10**20，i % 26在 Python 中没问题，但若后续做chr(i % 26 + 97)，则无问题；可一旦写成chr((i + offset) % N)，i + offset可能远超chr上限，需提前截断或校验
字符语义边界不可忽略
即使数值合法，chr(i) 返回的字符也可能引发业务逻辑异常。例如：
-
chr(0)是空字符（NUL），在 JSON、日志、数据库字段中常被截断或拒绝 -
chr(10)、chr(13)是换行/回车，在表单提交或 API 参数中可能被清洗或误解析 -
chr(0x200B)（零宽空格）、chr(0xFEFF)（BOM）等不可见字符，容易绕过前端校验，却在后端触发解析失败 - 中文常用区（U+4E00–U+9FFF）、emoji（U+1F600 起）等高码位字符，需验证传输链路（HTTP header、数据库 collation、终端显示）是否真正支持
实用测试策略建议
不靠穷举，聚焦三类组合用例：
-
数值边界 + 字符类型：如
chr(127)（最后 ASCII 可见字符）、chr(128)（首个 Latin-1 扩展）、chr(65535)（基本多文种平面末尾） -
取余临界输入：输入
i = N-1、N、N+1、-1、-N、-N-1，检查余数是否稳定落入目标区间，且chr不报错 -
业务敏感字符：显式加入
chr(0)、chr(9)（Tab）、chr(34)（双引号）、chr(92)（反斜杠）、chr(0x202E)（RTL 覆盖攻击字符）等，验证系统是否拦截、转义或静默丢弃
