1. 项目概述：为什么选择数据加密系统作为毕设？

又到了一年一度的毕业季，对于计算机相关专业的同学来说，选一个“好做、能过、有亮点”的毕设题目，简直比写代码本身还让人头疼。后台经常收到私信，问有没有那种“技术栈主流、工作量适中、答辩时老师能听懂且觉得有技术含量”的选题。今天，我就以一个过来人兼多年项目评审的身份，和大家聊聊“数据加密系统”这个选题。

乍一看，“数据加密”这个词听起来很高深，像是安全专业硕士才会碰的领域。但实际上，它恰恰是本科阶段一个非常理想的毕设方向。为什么这么说？首先，它的核心逻辑清晰：无非就是“明文输入 -> 加密算法处理 -> 密文输出”，以及反向的“密文输入 -> 解密算法处理 -> 明文输出”。这个流程本身不复杂，但足以支撑起一个完整的系统。其次，它的技术栈非常灵活，你可以用最熟悉的Java Spring Boot搭后端，用Vue或React写个简单的前端管理界面，数据库用MySQL或PostgreSQL存储加密后的密文和密钥信息，整个技术生态成熟，资料遍地都是，不怕卡壳。

更重要的是，这个选题的“弹性”很大。对于只想顺利毕业的同学，你可以实现一个基础的、针对文件或字符串的对称加密（比如AES），再做个简单的用户登录和操作日志，一个完整的Web系统就出来了。对于想冲一冲优秀论文的同学，你可以深入下去，加入非对称加密（RSA）、数字签名、密钥生命周期管理（生成、存储、轮换、销毁）、甚至结合国密算法（SM2/SM4），这深度和广度立刻就上来了。答辩时，你不仅可以演示系统功能，还能讲清楚背后的密码学原理和工程实现上的考量，这比你做一个纯CRUD的管理系统有说服力得多。

我当年带的几个学生，凡是选了类似“基于混合加密的文档安全管理系统”这类题目的，最后答辩分数都不错。老师普遍反馈是：选题有明确的现实意义（数据安全谁不关心？），技术实现有层次感（从应用到原理都能讲），工作量也肉眼可见。所以，如果你还在纠结，不妨认真考虑一下这个方向。接下来，我会把这个项目从“想法”到“成品”的完整路径，包括每个阶段的关键决策和最容易踩的坑，毫无保留地拆解给你看。

2. 核心需求与系统设计思路拆解

2.1 明确你的系统边界：到底要做什么？

动手之前，最忌讳的就是思路模糊。一个“数据加密系统”可以做得很大，比如像阿里云KMS（密钥管理服务）那样；也可以做得很小，就是一个网页版的加密工具。作为毕设，我们必须划定一个清晰且可行的范围。

核心功能模块，我建议聚焦以下四点：

1. 用户认证与权限管理：这是任何系统的基础。不需要搞得太复杂，实现一个基于用户名密码的登录即可。高级一点可以加个验证码防止爆破。权限方面，初期可以简单分为“管理员”和“普通用户”。管理员能查看所有操作日志，普通用户只能操作自己的数据。这块用Spring Security或Shiro可以轻松搞定，也是你展示Web开发基本功的地方。
2. 加密/解密核心服务：这是系统的灵魂。你需要提供至少两种类型的加密操作：
   • 对称加密：例如AES。用户上传一个文件或输入一段文本，选择一个密钥（或由系统生成），点击加密，得到密文。反之，输入密文和正确的密钥，得到原文。这里的关键是，密钥必须由用户自己提供或妥善保管，系统绝不存储用于解密的原始密钥。这涉及到密钥的安全传输和临时存储问题，后面会细说。
   • 非对称加密：例如RSA。用户可以生成一对公钥和私钥。公钥可以公开，用于加密数据；私钥自己保存，用于解密。这个场景非常适合模拟“安全通信”：用户A用用户B的公钥加密一段信息，只有用户B用自己的私钥才能解开。实现这个，能立刻让你的系统显得更“专业”。
3. 密钥管理：这是区分“玩具”和“系统”的关键。你不能让用户每次加密都手动输入一长串密钥。对于对称加密，可以设计一个“密钥库”模块，允许用户创建、命名、导入密钥。这些密钥在数据库存储时，必须本身被加密！通常的做法是，用一个固定的主密钥（Master Key）或由用户登录密码派生的密钥，来加密这些用户的工作密钥。对于非对称加密，则需要安全地存储用户的私钥（同样需要加密存储），并提供公钥的导出功能。
4. 操作日志审计：所有加密、解密、密钥生成等敏感操作，必须记录日志。包括操作人、操作时间、操作类型、涉及的文件名或数据指纹（如MD5）、使用的密钥ID等。这不仅是安全上的要求，也是你答辩时展示系统完整性和可追溯性的重要材料。

画个简单的架构图在脑子里（虽然不输出，但你要清楚）：用户从前端页面发起请求 -> 请求经过网关/Controller层 -> 调用Spring Security进行身份校验 -> 业务逻辑层处理加密/解密/密钥管理 -> 数据访问层与数据库交互（存储密文、加密后的密钥、日志）-> 将结果返回给前端。

2.2 技术栈选型：稳字当头，别追新

毕设不是技术试验田，稳定、资料多、社区活跃是首要原则。

• 后端：Spring Boot 2.7.x。为什么不是最新的3.x？因为2.7.x是长期支持版本，生态极其成熟，你遇到的任何问题几乎都能在CSDN、Stack Overflow、GitHub上找到答案。这是最重要的。
• 安全框架：Spring Security。它与Spring Boot集成度最高，虽然学习曲线稍陡，但一旦掌握，处理认证授权非常优雅。如果你的时间真的很紧，可以用Apache Shiro，它更轻量、配置更简单。
• 数据库：MySQL 8.0或PostgreSQL。两者皆可，任选一个你熟悉的。建议使用VARCHAR或TEXT存储Base64编码后的密文，使用BLOB存储二进制密文文件。别忘了给操作时间、用户ID等字段加索引。
• 前端：Vue 3 + Element Plus或React + Ant Design。选择你相对熟悉的一个。前端的目标是清晰、可用即可，不必追求炫酷。核心页面包括：登录页、仪表盘（展示统计信息）、加密/解密操作页、密钥管理页、操作日志查看页。
• 密码学库：Java Cryptography Architecture (JCA)。这是JDK自带的，直接使用Cipher、KeyGenerator、KeyPairGenerator等类。绝对不要自己实现加密算法！这是大忌。我们的工作是“正确地使用”这些久经考验的算法和库。
• 构建工具：Maven。简单直接，省心。

注意：很多同学想用国密算法（SM2/SM4）来体现创新性，这很好。但你需要引入Bouncy Castle这样的第三方Provider，并在代码中显式注册。这会给环境部署带来一点点复杂性（需要添加JAR包或配置安全策略文件），答辩时务必准备好如何解释这个步骤。如果时间有限，优先保证AES/RSA的稳定实现，国密可以作为加分项后期补充。

3. 核心模块实现与避坑详解

3.1 用户认证模块：第一个拦路虎

很多同学栽在第一步。Spring Security配置复杂，容易让人晕头转向。我的建议是，从一个最小化可用的配置开始。

核心步骤：

1. 引入spring-boot-starter-security依赖。
2. 创建一个配置类继承WebSecurityConfigurerAdapter（Spring Boot 2.x）或使用SecurityFilterChainBean（Spring Boot 2.7+推荐方式）。
3. 重点配置HttpSecurity：放行登录页面、注册页面、静态资源（如CSS/JS），其他所有请求都需要认证。
4. 实现UserDetailsService接口，从数据库加载用户信息（用户名、加密后的密码、角色）。
5. 密码存储必须加密！使用BCryptPasswordEncoder，这是目前存储密码的首选。千万不要用MD5或SHA-1，更别提明文存储。

@Configuration @EnableWebSecurity public class SecurityConfig { @Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http .authorizeHttpRequests(authz -> authz .requestMatchers("/login", "/register", "/css/**", "/js/**").permitAll() .anyRequest().authenticated() ) .formLogin(form -> form .loginPage("/login") .defaultSuccessUrl("/dashboard", true) .permitAll() ) .logout(logout -> logout .logoutSuccessUrl("/login?logout") .permitAll() ) .csrf().disable(); // 在开发阶段可以禁用，方便API测试，上线前必须重新考虑 return http.build(); } @Bean public PasswordEncoder passwordEncoder() { return new BCryptPasswordEncoder(); } }

避坑实践：

• 坑1：登录成功后的无限重定向。这通常是因为权限配置冲突或登录成功页面本身也需要认证。确保defaultSuccessUrl指向的路径在权限规则内是允许访问的。
• 坑2：csrf().disable()的滥用。在开发测试时为了方便，我们常禁用CSRF防护。但一定要知道，这是一个安全漏洞。在最终提交和答辩前，要么移除这行代码（启用CSRF），要么在前端表单中正确添加CSRF Token。这是体现你安全意识的细节。
• 坑3：密码编码器不匹配。在用户注册时，存入数据库的密码必须用BCryptPasswordEncoder编码。在登录校验时，Spring Security会自动使用同一个编码器进行比对。如果你手动测试数据库，会发现同一个密码每次加密的结果都不同，这是BCrypt的特性（盐值不同），是正常的。

3.2 对称加密（AES）实现：关键在于密钥处理

AES加密本身很简单，几行代码就能搞定。但工程上的难点在于密钥如何安全地“来”和“去”。

基础加密/解密代码片段：

import javax.crypto.Cipher; import javax.crypto.KeyGenerator; import javax.crypto.SecretKey; import javax.crypto.spec.SecretKeySpec; import java.util.Base64; public class AesUtil { private static final String ALGORITHM = "AES"; private static final String TRANSFORMATION = "AES/ECB/PKCS5Padding"; // 注意模式 // 生成一个AES密钥 public static String generateKey() throws Exception { KeyGenerator keyGen = KeyGenerator.getInstance(ALGORITHM); keyGen.init(256); // 指定密钥长度，256位更安全 SecretKey secretKey = keyGen.generateKey(); return Base64.getEncoder().encodeToString(secretKey.getEncoded()); } // 加密 public static String encrypt(String data, String base64Key) throws Exception { byte[] keyBytes = Base64.getDecoder().decode(base64Key); SecretKeySpec keySpec = new SecretKeySpec(keyBytes, ALGORITHM); Cipher cipher = Cipher.getInstance(TRANSFORMATION); cipher.init(Cipher.ENCRYPT_MODE, keySpec); byte[] encryptedBytes = cipher.doFinal(data.getBytes("UTF-8")); return Base64.getEncoder().encodeToString(encryptedBytes); } // 解密 public static String decrypt(String encryptedData, String base64Key) throws Exception { byte[] keyBytes = Base64.getDecoder().decode(base64Key); SecretKeySpec keySpec = new SecretKeySpec(keyBytes, ALGORITHM); Cipher cipher = Cipher.getInstance(TRANSFORMATION); cipher.init(Cipher.DECRYPT_MODE, keySpec); byte[] decodedBytes = Base64.getDecoder().decode(encryptedData); byte[] decryptedBytes = cipher.doFinal(decodedBytes); return new String(decryptedBytes, "UTF-8"); } }

避坑实践（重中之重）：

• 坑1：加密模式的选择。上面示例使用了ECB模式，这是最简单的，但极其不安全！相同的明文块会加密成相同的密文块，容易受到模式分析攻击。毕设中绝对不要用ECB！请使用CBC（需要初始化向量IV）或GCM（同时提供加密和完整性验证）模式。

  // 使用CBC模式，需要IV（初始化向量） private static final String TRANSFORMATION = "AES/CBC/PKCS5Padding"; // 在加密时生成一个随机的IV，并和密文一起存储/传输 // 解密时，需要同样的IV

• 坑2：密钥的存储与传输。这是核心安全考量。
  • 传输：前端用户输入密钥后，必须通过HTTPS（https://）协议传输到后端。在本地开发测试时，也要有这个意识。
  • 存储：系统如果需要帮用户“保存”密钥，绝不能明文存数据库。正确做法是：当用户创建密钥时，系统提示用户输入一个“主密码”（Master Password）。用这个主密码派生出一个密钥加密密钥（KEK），然后用KEK去加密用户的工作密钥（AES密钥），将加密后的结果存到数据库。解密时，用户再次输入主密码，系统用同样的方式派生出KEK，解密出工作密钥，再进行数据解密。主密码不由系统存储，只存在于用户记忆中。这模拟了密码管理器的核心逻辑。
• 坑3：字符编码。加密操作针对的是字节（byte[]）。在将字符串转换为字节，或将解密后的字节转换为字符串时，务必明确指定字符编码（如"UTF-8"），否则在不同环境下可能出现乱码。
• 坑4：异常处理。Cipher.doFinal()、密钥解码等操作可能抛出多种异常（BadPaddingException,IllegalBlockSizeException,InvalidKeyException等）。在前端要给用户友好的提示（如“密钥错误”、“数据已损坏”），而不是把一堆Java异常栈信息抛给用户。

3.3 非对称加密（RSA）与数字签名

RSA实现了加密和签名两个功能，理解它们的区别是亮点。

密钥对生成：

import java.security.KeyPair; import java.security.KeyPairGenerator; import java.util.Base64; public class RsaUtil { public static class KeyPairBase64 { public String publicKey; public String privateKey; } public static KeyPairBase64 generateKeyPair() throws Exception { KeyPairGenerator keyGen = KeyPairGenerator.getInstance("RSA"); keyGen.initialize(2048); // 密钥长度，2048是当前推荐的最小值 KeyPair pair = keyGen.generateKeyPair(); KeyPairBase64 keys = new KeyPairBase64(); keys.publicKey = Base64.getEncoder().encodeToString(pair.getPublic().getEncoded()); keys.privateKey = Base64.getEncoder().encodeToString(pair.getPrivate().getEncoded()); return keys; } }

加密（使用公钥）与解密（使用私钥）流程与AES类似，只是算法换成RSA/ECB/PKCS1Padding等。注意，RSA不适合加密大量数据，通常用于加密一个对称密钥（如AES密钥），然后用这个对称密钥去加密实际数据，这就是“混合加密”系统。

数字签名流程（体现数据完整性和身份认证）：

1. 签名：发送方用自己的私钥对数据的哈希值（如SHA256）进行加密，这个结果就是签名。
2. 验签：接收方用发送方的公钥对签名进行解密，得到哈希值A；同时自己计算接收数据的哈希值B。如果A等于B，则证明数据在传输过程中未被篡改，且确实来自持有对应私钥的发送方。

避坑实践：

• 坑1：数据长度限制。RSA算法本身有明文长度限制（与密钥长度有关）。直接加密长文本会报错。所以前面提到的“混合加密”是标准做法。
• 坑2：私钥的安全存储。用户的RSA私钥是最高机密。存储方案可以参照对称加密中“主密码保护工作密钥”的方式。即，用用户的主密码派生出的密钥，去加密用户的RSA私钥，然后存储加密后的结果。绝对不要将私钥明文存储在数据库或代码中。
• 坑3：签名与加密的混淆。一定要分清：公钥用于加密和验签，私钥用于解密和签名。加密是为了保密（只有私钥持有者能看），签名是为了防篡改和身份确认（任何人都能用公钥验证）。

3.4 数据库设计要点

数据库表不需要多复杂，但要清晰。

• user表：存用户基本信息，密码字段存储BCrypt加密后的字符串。
• symmetric_key表：存储用户加密后的对称密钥。字段包括：key_id,user_id,key_name,encrypted_key（被主密码加密后的密钥密文）,algorithm（如AES）,key_length,created_time。注意：encrypted_key字段需要足够长，建议用TEXT类型。
• asymmetric_key_pair表：存储用户的非对称密钥对。字段包括：key_pair_id,user_id,key_pair_name,encrypted_private_key（加密后的私钥）,public_key（公钥可以明文存储，因为它本身就是公开的）,algorithm（如RSA）,created_time。
• encryption_log表：操作日志。字段包括：log_id,user_id,operation_type（ENCRYPT/DECRYPT/SIGN/VERIFY等）,algorithm,key_id（关联使用的密钥）,source_data_hash（原始数据的哈希，用于追溯，而非存储明文）,result_status,ip_address,operation_time。
• encrypted_data表（可选）：如果你需要保存加密后的数据记录。字段包括：data_id,user_id,encrypted_content（Base64编码的密文）,associated_key_id,iv（如果加密模式需要）,created_time。

注意：source_data_hash字段的设计是一个隐私保护技巧。我们不存明文，甚至不存密文，只存一个哈希值。当需要审计“某用户是否加密过某份数据”时，我们可以用该数据的哈希值来查询日志。这既满足了审计需求，又避免了存储敏感数据本身。

4. 前端交互与用户体验关键点

前端的目标是让后端功能易于使用，并清晰地展示安全逻辑。

关键页面与交互设计：

1. 密钥管理页面：
   • 列表展示用户已有的对称/非对称密钥。
   • “创建密钥”按钮：弹出表单，让用户输入密钥名称、选择算法/长度、并设置一个“主密码”用于保护此密钥（对于对称密钥）或密钥对（对于非对称私钥）。创建成功后，将生成的密钥（或公钥）清晰地显示给用户一次，并提示其妥善保存（对于私钥，应提供下载功能）。之后，密钥就以加密形式存储在系统。
   • “使用密钥”操作：在加密/解密页面，通过下拉框选择已创建的密钥，并要求用户输入创建该密钥时使用的主密码。前端将主密码传输到后端，后端用它解密出工作密钥再进行操作。
2. 加密/解密操作页面：
   • 提供文本输入框和文件上传两种输入方式。
   • 明确的选择区：选择加密还是解密，选择对称加密还是非对称加密。
   • 根据选择动态切换控件：选对称加密，则显示密钥选择下拉框和主密码输入框；选非对称加密，若是加密则显示“接收方公钥”选择/输入框，若是解密则自动关联当前用户的私钥并要求输入主密码。
   • 结果展示区：将生成的密文（Base64格式）或解密后的明文清晰显示，并提供“复制到剪贴板”和“下载为文件”按钮。
3. 操作日志页面：
   • 以表格形式展示，支持按时间、操作类型、状态筛选。
   • 对于每条日志，可以查看详情（如使用的密钥ID、数据哈希等），但绝不显示任何密钥明文或数据明文。

避坑实践：

• 坑1：密钥的“一次可见性”。在密钥创建环节，很多系统设计不佳。务必在创建成功后，将密钥信息（尤其是非对称密钥对的私钥）完整地、醒目地展示给用户，并强烈建议其立即下载保存。因为之后系统里存储的只是加密后的版本，如果用户忘记主密码，原始私钥将永远无法恢复。这个风险必须明确告知用户。
• 坑2：主密码的传输。前端在发送主密码到后端时，虽然有了HTTPS，但也可以考虑在前端先进行一次哈希（例如SHA256）再传输。这样，即使HTTPS被某种方式窥探，攻击者得到的也是哈希值，而非原始主密码。后端再用这个哈希值进行后续的密钥派生。注意：这不同于密码存储时的BCrypt，这里只是为了传输安全。
• 坑3：大文件处理。如果支持文件加密，前端需要做文件大小限制和分片上传提示。后端加密大文件时，不能一次性读入内存，要使用CipherInputStream和CipherOutputStream进行流式处理，防止内存溢出（OOM）。

5. 部署、测试与答辩准备

5.1 系统部署与配置

开发完成后，你需要让老师在答辩现场能访问到你的系统。

• 本地部署：最简单。在你的笔记本上运行Spring Boot应用，前端打包后放在src/main/resources/static下或通过Nginx代理。确保老师在同一网络下能访问你的IP和端口。提前关闭防火墙或配置好规则。
• 云服务器部署：更专业。购买一个最基础的云服务器（学生常有优惠），安装JDK、MySQL、Nginx。将后端打包成JAR，前端打包成静态文件。通过Nginx反向代理到后端Spring Boot应用。务必为你的云服务器配置安全组，只开放必要的端口（如80, 443, 22）。
• 关键配置检查：
  • application.properties中数据库密码等敏感信息，不要硬编码。可以使用环境变量或JVM参数传入。
  • 确保生产环境禁用了csrf().disable()，或正确配置了CSRF Token。
  • 检查所有日志输出，避免在日志中打印密钥、密文等敏感信息。
  • 启用HTTPS。你可以使用自签名证书或Let‘s Encrypt申请免费证书。在Spring Boot中配置SSL，或在Nginx层面配置HTTPS反向代理。这是答辩时一个重要的加分项，体现了你对传输安全的重视。

5.2 系统性测试清单

不要只测试“高兴路径”（一切正常的情况）。必须测试异常和边界情况。

1. 功能测试：
   • 使用正确的密钥和主密码，能正常加密和解密文本/文件。
   • 使用错误的密钥或主密码，解密时应明确失败（提示“密钥错误”或“解密失败”），而不是抛出服务器500错误或得到乱码。
   • 非对称加密：用A的公钥加密，只能用A的私钥解密；用B的公钥加密的数据，用A的私钥解密应该失败。
   • 数字签名：对数据签名后，修改原始数据，验签应失败。
2. 安全测试：
   • 尝试未登录直接访问加密页面，应跳转到登录页。
   • 用户A登录后，能否通过修改URL参数访问到用户B的密钥或日志？这属于“水平越权”漏洞，需要通过后端在查询时严格校验user_id来防止。
   • 检查数据库，确认所有密钥字段（encrypted_key,encrypted_private_key）存储的都是密文，且不同用户的相同密钥，加密后的密文也不同（因为IV或盐值不同）。
3. 性能与兼容性测试：
   • 加密一个10MB的文件，观察内存占用和耗时是否在可接受范围。
   • 在不同浏览器（Chrome, Firefox, Edge）上测试前端页面功能是否正常。

5.3 答辩准备：如何讲好你的故事

答辩的核心是“展示”和“沟通”。你的系统就是你的作品，你要像产品经理一样介绍它。

• 演示脚本：
  1. 开场与问题引入：“各位老师好，我的毕设题目是《数据加密系统》。在当今数字化时代，数据安全日益重要。无论是个人隐私照片，还是企业的合同文档，都需要一种简单可靠的方式进行加密保护。因此，我设计并实现了这个系统...”
  2. 系统架构总览：用一张清晰的架构图（PPT或画图工具）快速展示前后端分离、核心模块组成。
  3. 核心功能演示：
     • 用户安全：演示注册、登录。强调密码是BCrypt加密存储。
     • 密钥安全生命周期：演示创建AES密钥。重点展示“主密码”保护机制，并强调密钥创建后仅显示一次，系统只存加密后的密钥。这是你系统的核心安全设计，一定要讲透。
     • 加密解密流程：选择一个文件，用刚才创建的密钥加密。下载密文文件。然后上传密文文件，选择同一密钥并输入主密码，成功解密。演示过程流畅。
     • 非对称加密与签名：生成一对RSA密钥。模拟场景：用户A用用户B的公钥加密一条消息“秘密计划”，发送出去。切换到用户B账号，用其私钥成功解密。再演示用户A对一份文档进行签名，用户B用A的公钥成功验签。
     • 审计与追溯：演示操作日志页面，展示所有操作都有记录。
  4. 技术难点与解决方案：主动提及你遇到的坑和如何解决的。例如：“在实现AES加密时，我最初使用了不安全的ECB模式，后来查阅资料改为了更安全的CBC模式，并妥善处理了初始化向量IV的存储问题。” 这体现了你的研究深度和解决问题的能力。
  5. 总结与展望：简要总结系统实现的功能和特点。可以提一下可能的改进方向，如“未来可以集成国密算法SM2/SM4”、“可以增加密钥的自动轮换机制”或“实现一个浏览器插件进行一键加密”。展示你的思考，但不要过度承诺。
• 准备问答：
  • 为什么选AES和RSA？答：AES是国际标准，安全高效，适合加密大量数据；RSA用于密钥交换和数字签名，是公钥基础设施的基石。两者结合是行业通用实践。
  • 你的系统安全吗？密钥丢了怎么办？答：系统的安全设计基于“主密码”模型。密钥由用户的主密码加密后存储，服务器不保存主密码。因此，安全性很大程度上取决于用户主密码的强度。如果用户丢失主密码，则其加密的数据将无法解密，这是基于“我们无法访问用户数据”的安全原则设计的，类似于密码管理器。
  • 和市面上加密软件比，你的创新点在哪？答：作为毕业设计，主要目标是深入理解并实践密码学原理在Web系统中的工程化应用。创新点可能不在于算法本身，而在于对密钥安全管理、用户操作审计以及混合加密流程的完整实现和整合，为一个具体的应用场景提供了可落地的解决方案原型。

记住，答辩老师可能不是密码学专家，他们更看重的是你能否将理论知识转化为一个可运行、逻辑清晰、考虑周全的系统。清晰地展示你的设计思路、实现细节和应对问题的思考过程，远比炫技更重要。这个项目做下来，你收获的将不仅仅是一个毕设，更是一套完整的、关于“如何安全地处理数据”的工程化思维。