1. 问：你们项目中有哪些地方用到了加密或解密？各自的目的是什么？
答： 在本项目中，加密和解密主要体现在以下几个方面：
- JWT（JSON Web Token）加密：在
web-server/utils/JWT.js中，用户登录后会生成加密的 JWT token，前端（如web-admin、web-company）在请求时携带 token，后端通过解密验证用户身份，实现了无状态的认证和授权。 - 密码加密存储：在用户注册和登录流程中，用户密码不会明文存储在数据库，而是通过加密（如 hash）后存储，防止数据泄露时密码被直接获取。
- 接口数据传输安全：虽然主要依赖 HTTPS，但部分敏感数据（如登录密码）在前端可进行一次简单加密（如 base64 或 AES），增加安全性。
- 上传文件名加密：在
web-server/public/avataruploads、newsuploads、productuploads目录下，上传的文件名经过 hash 处理，防止用户通过文件名推测内容。
2. 问：JWT 在你们项目中的加密和解密流程是怎样的？如何保证安全？
答： 在本项目中，JWT 的加密解密流程如下：
- 加密（签发）：用户登录成功后，后端（
web-server/utils/JWT.js）会用一个 secret key 对用户信息（如 userId、role）进行加密生成 token，返回给前端。 - 解密（验证）：前端每次请求需要认证的接口时（如用户信息、订单等），会在 header 里带上 token。后端通过同样的 secret key 对 token 进行解密和校验，判断其合法性和有效期。
- 安全措施：
- secret key 保存在服务器端，不暴露给前端。
- token 设置过期时间，防止被长期利用。
- 重要操作（如修改密码）时，需重新校验 token。
- token 只通过 HTTPS 传输，防止中间人攻击。
3. 问：你们项目中用户密码是如何加密存储的？为什么不能用明文？
答： 在本项目中，用户密码不会以明文形式存储在数据库。通常流程如下：
- 用户注册或修改密码时，前端（如
web-admin/web-company）将密码通过 HTTPS 传输到后端。 - 后端（如
web-server/models/UserModel.js）收到密码后，使用加密算法（如 bcrypt、md5+salt 等）对密码进行 hash 处理，再存入数据库。 - 用户登录时，输入的密码同样 hash 后与数据库中的 hash 进行比对。
- 这样即使数据库泄露，攻击者也无法直接获得用户明文密码，提升了安全性。
4. 问：前端如何安全地存储和传递 token？你们项目是怎么做的？
答： 在本项目中，token 的安全存储和传递方式如下：
- 存储：前端（如
web-admin/src/utils/token.ts、web-company/src/utils/token.ts）将 token 存储在localStorage或sessionStorage，并在每次请求时自动带上。 - 传递：通过 HTTP 请求的 header（如
Authorization: Bearer <token>）传递给后端。 - 安全措施：
- 只在 HTTPS 下传递 token，防止被窃听。
- 避免将 token 暴露在 URL、日志等不安全位置。
- 定期清理过期 token，用户登出时及时移除。
- 对于高安全需求场景，可考虑将 token 存储在 httpOnly 的 cookie 中，防止 XSS 攻击。
5. 问：你们项目中有没有用到对称加密或非对称加密？举例说明应用场景。
答： 在本项目中，主要用到的是对称加密（如 JWT 的 HMAC、文件名 hash），但也可以扩展到非对称加密：
- 对称加密：如 JWT token 的签名和验证，通常用 HMAC（基于 secret key），前后端共享密钥。
- 文件名加密：上传文件时，文件名通过 hash（如 md5）处理，属于对称加密的应用，防止文件名泄露敏感信息。
- 非对称加密（可扩展）：如果有更高安全需求（如前端加密敏感数据），可用 RSA 公钥加密，后端用私钥解密。虽然目前项目主要用对称加密，但架构上支持非对称加密的扩展。
