异或能用于简单加解密，因a^b^b==a；需注意编码一致、密钥非空、字节处理及循环复用逻辑。
为什么异或（^）能当加密用？
因为 a ^ b ^ b == a，两次异或同一个密钥就还原——这是它做简单加解密的唯一前提。不是“安全算法”，只是位运算的数学特性。适合教学、配置项混淆、临时掩码这类不涉及真实敏感数据的场景。
常见错误现象：String.getBytes() 编码不一致导致解密乱码；用 char 当密钥却没转成 int，结果只取低8位；对空字符串或 null 直接操作抛 NullPointerException。
- 密钥必须是
byte或能明确映射为byte的值（比如"key".getBytes(StandardCharsets.UTF_8)） - 不要用
new String(byte[])直接构造结果，务必指定编码，例如new String(decryptedBytes, StandardCharsets.UTF_8) - 异或不改变字节数组长度，所以加密后长度 = 原文长度，别指望它压缩或扩增数据
Java里怎么写一个可复用的异或加解密方法？
核心就是遍历字节数组，逐字节跟密钥字节异或。密钥短于原文时得循环复用——这是最容易写错的地方：有人用 i % key.length 却忘了 key.length == 0 会抛异常。
public static byte[] xorEncryptDecrypt(byte[] data, byte[] key) {
if (data == null || key == null || key.length == 0) {
throw new IllegalArgumentException("data and non-empty key required");
}
byte[] result = new byte[data.length];
for (int i = 0; i < data.length; i++) {
result[i] = (byte) (data[i] ^ key[i % key.length]);
}
return result;
}
- 输入输出都是
byte[]，避免在String和byte[]之间无意识转换丢失信息 - 密钥建议用
StandardCharsets.UTF_8编码，别依赖平台默认编码 - 如果密钥是单字符（比如
'x'），记得先转成byte：(byte) 'x'，而不是直接传char
实际调用时怎么避免中文变问号或乱码？
根本原因不是异或，是字符串和字节之间的编码没对齐。比如用 GBK 编码的字符串，却用 UTF_8 解回去，必然出错。
立即学习“Java免费学习笔记（深入）”；
- 统一用
StandardCharsets.UTF_8处理所有String ↔ byte[]转换 - 测试时优先用英文+数字组合，确认逻辑正确后再加中文
- 打印调试时别只看
new String(bytes)输出，用Arrays.toString(bytes)看原始字节是否对称（加密前后字节序列应满足异或关系）
这个方案有什么硬伤？哪些地方不能碰？
它连“玩具级加密”都算勉强——没有密钥派生、无随机盐、无完整性校验。一旦密钥泄露或被猜中，所有数据瞬间裸奔。
- 绝不能用于密码、token、用户身份证号等真实敏感字段
- 别把密钥写死在代码里（比如
new byte[]{0x1a, 0x2b}），至少从配置文件或环境变量读 - 如果需要多端互通，确保所有端都用同一套编码和密钥字节序列，Java 的
"abc".getBytes()在 Windows 和 Linux 下默认编码可能不同
真正卡住人的往往不是异或本身，而是字节和字符那层薄薄的、但必须精确控制的转换边界。
