Java AES加密实战：从原理到生产环境避坑指南

1. 项目概述：为什么Java开发者必须掌握AES加密？

在任何一个涉及用户数据、支付信息或敏感配置的Java项目中，加密都是一个绕不开的话题。你可能在面试中被问到“AES和DES有什么区别？”，也可能在开发中遇到“Invalid AES key length”这样的异常。AES（高级加密标准）作为目前全球公认最安全、应用最广泛的对称加密算法，早已不是密码学专家的专属，而是每一位Java开发者工具箱里的必备品。无论是保护数据库里的用户密码（虽然更推荐bcrypt）、加密配置文件中的API密钥，还是实现安全的网络通信，AES都是最可靠的选择之一。

我见过太多项目，加密部分要么是网上随便抄一段代码，密钥硬编码在源码里；要么是对加密模式、填充方式一知半解，埋下了严重的安全隐患。这篇文章，我将从一个有十多年经验的开发者视角，带你彻底搞懂在Java中如何正确、安全地实现AES加密。我们不仅会写出能跑的代码，更要深入理解每一步背后的“为什么”，包括密钥生成、模式选择、初始向量（IV）的处理，以及那些官方文档里不会写的“坑”。无论你是正在准备面试八股文，还是急需在项目中落地一个安全的加密模块，这篇内容都能给你一份可以直接“抄作业”的实战指南。

2. AES加密的核心原理与Java实现选型

在动手写代码之前，我们必须先理解AES是什么，以及在Java生态中我们有哪些选择。这能帮你避免“知其然不知其所以然”，在遇到问题时能快速定位。

2.1 AES算法简析：不只是“加密”那么简单

AES是一种分组对称加密算法。“对称”意味着加密和解密使用同一把密钥，这带来了加解密速度快的优点，但密钥分发和管理需要额外安全通道。“分组”则指它一次处理固定长度的数据块（AES是128位，即16字节）。对于超过16字节的数据，就需要用到“模式”来迭代加密。

这里的关键是，当你使用AES时，你实际上是在使用一个“算法/模式/填充”的组合。例如，AES/CBC/PKCS5Padding。

• 算法：就是AES本身，负责最核心的加密变换。
• 模式：定义了如何重复应用算法来加密长于一个块的消息。常见的有：
  • ECB：电子密码本模式。每个块独立加密，相同的明文块会产生相同的密文块。绝对不要用于加密有意义的数据，因为它不能隐藏数据模式，安全性很差。
  • CBC：密码分组链接模式。每个明文块先与前一个密文块进行异或操作后再加密。它需要一个初始向量来启动这个过程。这是目前最常用的模式之一，安全性好。
  • GCM：伽罗瓦/计数器模式。这是一种“认证加密”模式，不仅能保密，还能验证数据在传输中未被篡改（提供完整性校验）。在现代应用（如TLS 1.3）中越来越流行。
• 填充：因为AES是分组加密，当最后一块数据不足16字节时，需要填充至满块。PKCS5Padding（在Java中对应PKCS5Padding，但实际处理16字节块时标准叫PKCS7Padding）是最常用的填充方式。

注意：你可能会在搜索时看到错误“cannot find any provider supporting AES/CBC/PKCS7Padding”。这是因为Java标准命名使用PKCS5Padding，但它在处理AES的16字节块时，其逻辑与PKCS7Padding是相同的。直接使用PKCS5Padding即可。

2.2 Java中的加密支持：JCA与第三方库

Java通过Java密码体系结构提供加密服务。核心类是javax.crypto.Cipher，它是我们进行加密解密的入口。

1. 使用标准JCA（Java Cryptography Architecture）这是最基础、无需引入额外依赖的方式。但默认的“SunJCE”提供程序可能不支持所有算法和密钥长度（尤其是无限强度加密策略受当地法律限制时）。对于大多数常见的AES-128/192/256操作，它已经足够。

2. 使用Bouncy Castle库这是一个非常流行的第三方密码学提供者库。为什么需要它？

• 支持更广泛的算法和模式（如上面提到的GCM模式，在旧版本JDK中标准提供者可能不支持）。
• 提供了PKCS7Padding等更明确的填充名称。
• 通常不受JRE的默认强度策略限制。 在项目中引入Bouncy Castle后，你可以通过Security.addProvider(new BouncyCastleProvider())来注册它，然后在获取Cipher实例时指定该提供者。

选型建议：

• 对于大多数国内项目，使用标准JCA实现AES/CBC/PKCS5Padding或AES/ECB/PKCS5Padding（仅限特定场景）就足够了，这是最简单、依赖最少的方式。
• 如果你需要GCM模式、或者遇到标准库不支持的算法组合，或者需要更丰富的密码学工具，那么引入Bouncy Castle是更好的选择。本文的示例将主要基于标准JCA，并在关键处指出Bouncy Castle的差异。

3. 实战：使用Java标准库实现AES加解密

理论说再多，不如一行代码。我们从一个最基础的、使用CBC模式的AES加解密工具类开始，并逐步完善它。

3.1 基础工具类搭建：AESUtil

我们的目标是创建一个线程安全、易于使用的工具类。首先，定义算法、模式和填充的组合。

import javax.crypto.Cipher; import javax.crypto.KeyGenerator; import javax.crypto.SecretKey; import javax.crypto.spec.IvParameterSpec; import javax.crypto.spec.SecretKeySpec; import java.security.NoSuchAlgorithmException; import java.security.SecureRandom; import java.util.Base64; public class AESUtil { // 指定算法、模式、填充 private static final String ALGORITHM = "AES"; private static final String TRANSFORMATION = "AES/CBC/PKCS5Padding"; // AES块大小是16字节 private static final int BLOCK_SIZE = 16; // 密钥长度：128, 192, 256 位 private static final int KEY_SIZE = 128; private static final SecureRandom secureRandom = new SecureRandom(); }

关键点解析：

• TRANSFORMATION: 这里我们选择了AES/CBC/PKCS5Padding。这是一个安全且通用的选择。
• KEY_SIZE: 设置为128位。你也可以使用192或256位，但请注意，使用256位可能需要安装Java的“无限强度管辖权策略文件”，否则会抛出InvalidKeyException。
• SecureRandom: 用于生成密码学安全的随机数（密钥和IV），绝对不要用java.util.Random替代。

3.2 密钥的生成与管理：安全第一道防线

密钥是加密的根基，密钥泄露意味着所有加密数据都可能被破解。

1. 生成随机密钥

/** * 生成一个随机的AES密钥 * @return 生成的SecretKey对象 */ public static SecretKey generateKey() throws NoSuchAlgorithmException { KeyGenerator keyGen = KeyGenerator.getInstance(ALGORITHM); // 初始化密钥生成器，指定长度和随机源 keyGen.init(KEY_SIZE, secureRandom); return keyGen.generateKey(); } /** * 将密钥转换为Base64编码的字符串，便于存储或传输 * @param secretKey 密钥 * @return Base64编码的密钥字符串 */ public static String keyToString(SecretKey secretKey) { return Base64.getEncoder().encodeToString(secretKey.getEncoded()); } /** * 从Base64编码的字符串还原SecretKey对象 * @param keyStr Base64编码的密钥字符串 * @return 还原的SecretKey对象 */ public static SecretKey stringToKey(String keyStr) { byte[] decodedKey = Base64.getDecoder().decode(keyStr); // 使用SecretKeySpec来重建密钥。第一个参数是密钥字节，第二个是算法名。 return new SecretKeySpec(decodedKey, ALGORITHM); }

实操心得：

• generateKey()方法每次调用都会产生一个全新的随机密钥。对于生产环境，一个常见的做法是在应用启动时生成一个密钥，然后将其安全地存储在环境变量或硬件安全模块中，而不是每次加密都生成新密钥。
• keyToString()和stringToKey()这对方法非常实用。你不能（也不应该）直接保存SecretKey对象。通常的做法是将密钥的字节数组进行Base64编码后，存入配置文件（需加密）、数据库或密钥管理服务。切记，Base64不是加密！它只是编码，任何人拿到这个字符串都能还原出密钥。所以存储和传输这个字符串时，必须通过其他安全手段进行保护。

2. 关于密钥长度异常热搜词里提到了一个错误：java.security.invalidkeyexception: invalid aes key length: 14 bytes。这个异常非常典型。

• AES密钥长度必须是128位（16字节）、192位（24字节）或256位（32字节）。
• 这个错误说明你提供的密钥材料是14字节，不符合要求。通常是因为你用一个密码字符串（如“myPassword123”）直接作为密钥字节。绝对不要这样做！正确的做法是从一个密码派生出符合长度的密钥，这需要用到基于密码的密钥派生函数，如PBKDF2。

import javax.crypto.SecretKeyFactory; import javax.crypto.spec.PBEKeySpec; import javax.crypto.spec.SecretKeySpec; import java.security.spec.KeySpec; /** * 从一个密码和盐派生出一个AES密钥（使用PBKDF2） * @param password 密码字符串 * @param salt 盐值（必须是随机生成的，至少8字节） * @param keyLength 密钥长度（128, 192, 256） * @return 派生出的SecretKey */ public static SecretKey deriveKeyFromPassword(String password, byte[] salt, int keyLength) throws Exception { // 将密钥长度转换为对应的密钥位数 int keyBits = keyLength; // 迭代次数，越高越安全但越慢，建议至少10000次 int iterationCount = 65536; // PBKDF2WithHmacSHA256是当前推荐的安全算法 SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256"); KeySpec spec = new PBEKeySpec(password.toCharArray(), salt, iterationCount, keyBits); // 派生出的密钥还不是AES密钥，需要包装一下 byte[] derivedKeyBytes = factory.generateSecret(spec).getEncoded(); return new SecretKeySpec(derivedKeyBytes, ALGORITHM); }

使用示例：如果你想用用户密码来加密数据，应该先调用此方法生成一个合规的密钥，而不是直接用密码的getBytes()。

3.3 初始向量（IV）的处理：CBC模式的安全核心

在CBC模式中，IV用于确保即使相同的明文，加密后也会产生不同的密文。IV不需要保密，但必须是不可预测的（最好是密码学安全的随机数），并且对于同一把密钥，每次加密都应该使用不同的IV。

1. 生成并处理IV

/** * 生成一个随机的初始向量（IV） * @return 16字节的IV字节数组 */ public static byte[] generateIv() { byte[] iv = new byte[BLOCK_SIZE]; // AES块大小是16字节 secureRandom.nextBytes(iv); return iv; } /** * 加密方法（包含IV生成） * @param plaintext 明文文本 * @param secretKey 密钥 * @return 一个包含IV和密文的Base64字符串（格式：IV:密文） */ public static String encryptWithIv(String plaintext, SecretKey secretKey) throws Exception { // 1. 生成随机IV byte[] iv = generateIv(); IvParameterSpec ivSpec = new IvParameterSpec(iv); // 2. 初始化Cipher为加密模式 Cipher cipher = Cipher.getInstance(TRANSFORMATION); cipher.init(Cipher.ENCRYPT_MODE, secretKey, ivSpec); // 3. 执行加密 byte[] plaintextBytes = plaintext.getBytes(java.nio.charset.StandardCharsets.UTF_8); byte[] ciphertextBytes = cipher.doFinal(plaintextBytes); // 4. 将IV和密文一起编码返回。IV是公开的，所以可以和密文一起存储/传输。 // 常见格式：IV + 密文，或者用分隔符如“:”连接两者的Base64。 String ivBase64 = Base64.getEncoder().encodeToString(iv); String ciphertextBase64 = Base64.getEncoder().encodeToString(ciphertextBytes); // 使用“:”分隔，方便解密时拆分 return ivBase64 + ":" + ciphertextBase64; }

关键点解析：

• generateIv()：使用SecureRandom生成一个16字节的随机IV。
• encryptWithIv方法：它将生成的IV和加密后的密文一起，用Base64编码后，通过一个分隔符（这里用冒号:）拼接成一个字符串返回。这是处理IV的一种常见模式。
• 为什么IV要随机且唯一？如果固定IV，那么用相同密钥加密的相同明文开头部分，其密文也会相同。攻击者可能通过分析密文模式推断出信息。随机IV彻底消除了这种关联性。

2. 对应的解密方法

/** * 解密方法（处理带IV的密文字符串） * @param encryptedText 加密返回的字符串（格式：IV的Base64:密文的Base64） * @param secretKey 密钥（必须与加密时相同） * @return 解密后的明文 */ public static String decryptWithIv(String encryptedText, SecretKey secretKey) throws Exception { // 1. 拆分字符串，获取IV和密文 String[] parts = encryptedText.split(":"); if (parts.length != 2) { throw new IllegalArgumentException("Invalid encrypted text format"); } byte[] iv = Base64.getDecoder().decode(parts[0]); byte[] ciphertextBytes = Base64.getDecoder().decode(parts[1]); // 2. 使用IV初始化Cipher为解密模式 IvParameterSpec ivSpec = new IvParameterSpec(iv); Cipher cipher = Cipher.getInstance(TRANSFORMATION); cipher.init(Cipher.DECRYPT_MODE, secretKey, ivSpec); // 3. 执行解密 byte[] plaintextBytes = cipher.doFinal(ciphertextBytes); return new String(plaintextBytes, java.nio.charset.StandardCharsets.UTF_8); }

3.4 完整的工具类与使用示例

将以上方法组合起来，我们就得到了一个基础但功能完整的AES工具类。下面是一个完整的使用示例：

public class AESUtil { // ... (常量定义、密钥生成、派生、IV生成等方法见上文) // 一个更集成的加密方法，内部处理密钥和IV的生成（适用于临时加密场景） public static String encrypt(String plaintext) throws Exception { SecretKey key = generateKey(); byte[] iv = generateIv(); IvParameterSpec ivSpec = new IvParameterSpec(iv); Cipher cipher = Cipher.getInstance(TRANSFORMATION); cipher.init(Cipher.ENCRYPT_MODE, key, ivSpec); byte[] cipherText = cipher.doFinal(plaintext.getBytes(StandardCharsets.UTF_8)); // 返回：密钥的Base64 : IV的Base64 : 密文的Base64 return keyToString(key) + "::" + Base64.getEncoder().encodeToString(iv) + "::" + Base64.getEncoder().encodeToString(cipherText); } // 对应的解密方法 public static String decrypt(String encryptedBundle) throws Exception { String[] parts = encryptedBundle.split("::"); if (parts.length != 3) { throw new IllegalArgumentException("Invalid bundle format"); } SecretKey key = stringToKey(parts[0]); byte[] iv = Base64.getDecoder().decode(parts[1]); byte[] cipherText = Base64.getDecoder().decode(parts[2]); IvParameterSpec ivSpec = new IvParameterSpec(iv); Cipher cipher = Cipher.getInstance(TRANSFORMATION); cipher.init(Cipher.DECRYPT_MODE, key, ivSpec); byte[] plainText = cipher.doFinal(cipherText); return new String(plainText, StandardCharsets.UTF_8); } // 主方法测试 public static void main(String[] args) { try { String originalText = "这是一段需要加密的敏感信息，比如身份证号：330101199001011234"; System.out.println("原始文本: " + originalText); // 方法1：使用集成方法（自动生成密钥和IV） String encryptedBundle = encrypt(originalText); System.out.println("加密后Bundle: " + encryptedBundle); String decryptedText = decrypt(encryptedBundle); System.out.println("解密后文本: " + decryptedText); System.out.println("匹配结果: " + originalText.equals(decryptedText)); System.out.println("---"); // 方法2：使用固定密钥和显式IV处理（更接近生产环境） SecretKey fixedKey = generateKey(); String keyStr = keyToString(fixedKey); System.out.println("生成并保存的密钥(Base64): " + keyStr); String encryptedWithIv = encryptWithIv(originalText, fixedKey); System.out.println("加密结果(IV:Cipher): " + encryptedWithIv); SecretKey restoredKey = stringToKey(keyStr); // 从存储的字符串恢复密钥 String decryptedWithIv = decryptWithIv(encryptedWithIv, restoredKey); System.out.println("使用恢复密钥解密: " + decryptedWithIv); } catch (Exception e) { e.printStackTrace(); } } }

4. 进阶话题与生产环境实践

掌握了基础实现后，我们需要关注如何在真实、复杂的生产环境中安全、高效地使用AES。

4.1 加密模式的选择：CBC vs GCM

我们之前一直用CBC，它是经过时间考验的模式。但对于现代应用，GCM模式是更推荐的选择。GCM同时提供保密性（加密）和认证性（防篡改），而且它通常比“CBC + 独立的HMAC认证”更高效。

使用GCM模式（需要JDK 8+，或使用Bouncy Castle）

import javax.crypto.spec.GCMParameterSpec; public class AESGCMUtil { private static final String TRANSFORMATION = "AES/GCM/NoPadding"; // GCM模式不需要额外填充 private static final int TAG_LENGTH_BIT = 128; // 认证标签长度，128位是标准且安全的 private static final int IV_LENGTH_BYTE = 12; // GCM推荐使用12字节（96位）的IV public static byte[] generateIv() { byte[] iv = new byte[IV_LENGTH_BYTE]; new SecureRandom().nextBytes(iv); return iv; } public static byte[] encrypt(byte[] plaintext, SecretKey key) throws Exception { byte[] iv = generateIv(); GCMParameterSpec gcmSpec = new GCMParameterSpec(TAG_LENGTH_BIT, iv); Cipher cipher = Cipher.getInstance(TRANSFORMATION); cipher.init(Cipher.ENCRYPT_MODE, key, gcmSpec); byte[] ciphertext = cipher.doFinal(plaintext); // 同样，需要将IV和密文一起存储 ByteBuffer byteBuffer = ByteBuffer.allocate(iv.length + ciphertext.length); byteBuffer.put(iv); byteBuffer.put(ciphertext); return byteBuffer.array(); } public static byte[] decrypt(byte[] ciphertextWithIv, SecretKey key) throws Exception { ByteBuffer byteBuffer = ByteBuffer.wrap(ciphertextWithIv); byte[] iv = new byte[IV_LENGTH_BYTE]; byteBuffer.get(iv); byte[] ciphertext = new byte[byteBuffer.remaining()]; byteBuffer.get(ciphertext); GCMParameterSpec gcmSpec = new GCMParameterSpec(TAG_LENGTH_BIT, iv); Cipher cipher = Cipher.getInstance(TRANSFORMATION); cipher.init(Cipher.DECRYPT_MODE, key, gcmSpec); return cipher.doFinal(ciphertext); } }

GCM使用要点：

1. NoPadding：GCM模式本身不要求填充。
2. IV长度：推荐12字节，兼顾性能和安全性。
3. 认证标签：TAG_LENGTH_BIT指定了完整性校验码的长度，128位是安全标准。
4. 异常处理：GCM解密时如果密文被篡改，doFinal()方法会抛出AEADBadTagException，这是一个重要的安全特性。

4.2 密钥的生命周期管理

这是比选择算法模式更关键、也更容易出错的部分。

1. 密钥存储

• 绝对禁止：将密钥硬编码在源代码中、提交到版本控制系统（如Git）。
• 推荐做法：
  • 开发/测试环境：将Base64编码的密钥放在环境变量中。
  • 生产环境：使用专业的密钥管理服务，如云服务商提供的KMS（密钥管理服务）、HashiCorp Vault等。这些服务提供密钥的生成、存储、轮换和访问审计。
  • 退而求其次：如果无法使用KMS，可以将加密后的密钥存储在配置中心或数据库中，而用来加密这个密钥的“主密钥”则通过环境变量或启动参数注入。

2. 密钥轮换一把密钥不应该无限期使用。应制定策略定期轮换密钥。轮换后，旧密钥加密的数据需要用新密钥重新加密，或者系统需要能同时支持新旧密钥解密（在过渡期内）。

4.3 性能考量与最佳实践

• Cipher对象复用：Cipher对象的初始化（init方法）开销较大。对于需要高频加解密的场景（如网络报文），可以考虑使用ThreadLocal或对象池来复用已初始化的Cipher实例。
• 选择合适密钥长度：AES-128对于绝大多数场景已足够安全，且比AES-256更快。除非有极高的安全要求（如国家机密），否则128位是平衡安全与性能的最佳选择。
• 数据量与大文件：对于大文件，不应一次性读入内存进行加密。应使用流式操作：

  try (InputStream in = new FileInputStream("input.txt"); OutputStream out = new FileOutputStream("encrypted.aes"); CipherOutputStream cos = new CipherOutputStream(out, cipher)) { byte[] buffer = new byte[8192]; int nread; while ((nread = in.read(buffer)) > 0) { cos.write(buffer, 0, nread); } cos.flush(); }

5. 常见问题排查与实战避坑指南

根据我多年的经验，下面这些问题是开发者最常遇到的“坑”。

5.1 异常与错误大全

5.2 那些“官方文档没写”的实操心得

1. 关于Base64编码：网络传输或文本存储密文时，必须使用Base64编码。但要注意，Base64有不同变种（标准、URL安全、MIME）。Java中Base64.getEncoder()是标准编码器，可能包含+和/，不适合放在URL中。此时应使用Base64.getUrlEncoder()（不填充）和Base64.getUrlDecoder()。

2. IV的存储：我强烈推荐将IV和密文一起存储（如用分隔符拼接）。不要尝试在加解密双方“约定”一个固定IV，这是非常危险的做法。IV的唯一要求是不可预测，所以每次加密都随机生成，并随密文带走即可。

3. 线程安全：Cipher对象本身不是线程安全的。不要在多个线程中共享一个Cipher实例，除非进行外部同步。更好的做法是为每个线程或每次操作创建新实例，或者使用ThreadLocal。

4. 算法字符串的坑：Cipher.getInstance(“AES”)这种写法，在不同JRE实现下，默认的模式和填充可能不同（可能是AES/ECB/PKCS5Padding）。为了确保可移植性和行为一致，永远使用完整的转换字符串，如AES/CBC/PKCS5Padding。

5. 处理“不足一个块”的数据：即使你只加密一个字节，在CBC模式下（使用PKCS5Padding）也会输出一个完整的16字节块（因为填充）。解密后会自动去除填充。这是正常现象。GCM模式（NoPadding）则没有这个问题。

6. 单元测试：为你的加密工具类编写单元测试。测试用例应包括：正常加解密、空字符串、超长字符串、使用固定密钥和IV确保结果可重现（仅用于测试）、以及故意使用错误密钥/IV解密应抛出预期异常。

5.3 面试高频问题精讲

结合热搜词里的“java面试八股文”，这里剖析几个深一点的问题：

Q1: AES的ECB模式为什么不安全？能举个例子吗？A1: ECB模式每个块独立加密。假设加密一张有简单图案的图片，其密文仍然会保留原图的轮廓。对于结构化文本，如果存在重复的块（如JSON中大量相同的空格或固定字段），攻击者也能看出模式。而CBC模式通过IV和链式操作，使得每个密文块都依赖于之前的所有明文块，彻底打乱了这种模式。

Q2: 如何选择AES的密钥长度？128位够用吗？A2: 从当前计算能力来看，暴力破解AES-128的密钥需要耗费远超宇宙年龄的时间，理论上非常安全。AES-256提供的是“抗量子计算”的额外安全边际，但会带来约40%的性能损耗。对于绝大多数商业应用，AES-128完全足够。选择256位更多是出于合规或政策要求。

Q3: 对称加密（如AES）和非对称加密（如RSA）结合使用的典型场景是什么？A3: 这是HTTPS/SSL/TLS的经典模式。具体流程是：

1. 客户端使用服务器的RSA公钥加密一个随机生成的“会话密钥”（通常是对称密钥，如AES密钥）。
2. 服务器用自己的RSA私钥解密，获得这个会话密钥。
3. 随后，双方使用这个会话密钥进行高效的AES对称加密通信。 这样做结合了非对称加密便于密钥分发的优点，和对称加密速度快、适合大数据量的优点。

Q4: 你在项目中如何管理加密密钥？A4: 这是一个考察工程实践的问题。可以这样回答： “我们避免将密钥写在代码或配置文件中。在开发环境，密钥来自环境变量。在生产环境，我们使用[云厂商]的KMS服务。应用启动时，向KMS请求解密一个本地加密的配置文件，该文件包含数据加密密钥（DEK）的密文。KMS返回DEK的明文用于运行时加解密。同时，我们制定了密钥轮换策略，每年轮换一次DEK，轮换期间新旧密钥并存以解密历史数据。”

掌握Java中的AES加密，远不止是调用Cipher.getInstance那么简单。从理解算法模式的选择，到安全地生成和管理密钥、处理IV，再到避免性能陷阱和应对各种异常，每一个环节都需要仔细考量。我希望这篇超过五千字的详细拆解，能帮你建立起一套完整、可落地的AES加密实践方案。记住，加密的目的是保障安全，而错误的使用方式本身就会成为最大的安全漏洞。在实现任何加密功能前，多问几个“为什么”，多考虑几个“如果……会怎样”，才能写出真正让人放心的代码。