在对接过的电商平台中，小米有品接口在数据安全设计上有一个显著特征：几乎所有关键业务数据（包括订单推送报文、发货请求参数、库存修改请求体）在传输过程中都是整体加密的。这与许多平台“部分字段加密”的模式截然不同。开发者必须首先完成数据的AES加密和解密，才能触及业务逻辑本身。理解这套加密体系的完整链路，是小米有品接口集成中最基础也最容易被低估的技术门槛。

一、加密算法与密钥体系

小米有品接口采用AES/ECB/PKCS5Padding算法对data字段的内容进行整体加密，密钥长度支持256bit。加密密钥（aesKey）与签名密钥（token或key）是两套独立的凭证：aesKey用于加密和解密data字段的原始JSON内容，而token用于生成请求签名sign。二者均由小米有品在商家接入时分配，混淆使用将导致加密失败或签名校验不通过。

加密前的data内容在V2版本中为JSON格式，且请求参数变更为数组格式，即JSON对象外需额外封装为[{}]。这一格式要求与V1版本不同，从V1迁移的开发者如果沿用旧的参数封装方式，即使加密算法正确，也会因格式不匹配而被服务端拒绝。

二、请求链路的加密与签名顺序

一个完整的发往小米有品的请求，其数据流经过三个转换步骤。第一步，组装原始业务JSON，例如单次发货接口的原始参数包含orderId、expressSn、expressName、itemList等字段。第二步，使用aesKey对原始JSON进行AES加密，得到密文data。第三步，构造签名字符串并进行MD5：签名的原始字符串格式为data=加密后的data内容&partnerId=商户标识×tamp=11位时间戳+签名密钥token，然后整体进行MD5加密得到sign。

这个顺序不可颠倒：必须先完成data的加密，再将密文data嵌入签名原始串。如果先计算签名再加密，签名将无法被服务端验证。

三、响应与推送报文的解密

小米有品接口的加密是双向的。服务端返回的响应以及订单推送报文，其data字段同样是加密的。订单推送的请求体结构为{"partnerId":88,"data":"加密字符串","sign":"...","timestamp":"..."}，外层没有数组格式，这一点与请求时的数组封装不同。开发者需要使用相同的aesKey对data字段进行解密，解密方式与加密相反，即可得到明文的业务报文。

由于解密操作需要在每一次接口调用和每一次推送接收时执行，建议将加密/解密逻辑封装为独立的底层组件，统一管理aesKey的加载、填充模式的配置以及异常处理。在Spring等框架中，可以通过AesUtils工具类或自定义的HttpMessageConverter来透明化加解密过程，避免业务代码中散落大量的加密调用。

四、安全与运维实践

aesKey和token属于高敏感凭证，不应硬编码在代码或配置文件中，而应通过密钥管理服务或环境变量注入。在日志输出中，必须确保原始JSON和aesKey不被打印。一个容易被忽视的风险点是：当解密失败时，如果直接抛出包含密文或密钥的异常信息，可能将敏感数据泄露到日志系统中。解密组件的异常处理应只记录“解密失败”这一事实，而不记录任何密钥或密文的片段。

对于需要同时对接多个小米有品店铺的ISV或商家，不同店铺可能拥有不同的aesKey和partnerId。系统需要为每个店铺维护独立的凭证上下文，在请求发起和响应处理时正确路由到对应的密钥和商户标识，避免跨店铺的凭证混用。