简介：这份资源面向使用PHP开发微信小程序的开发者，聚焦用户信息获取中的手机号与OpenID两大核心环节，提供可直接参考的原始实现文件。包内共2个PHP文件，压缩包约3KB，分别承担微信业务逻辑控制与敏感数据解密职责：前者封装授权引导、code换取OpenID、调用微信接口等流程，后者基于微信官方解密类处理加密数据包，还原用户手机号。资源虽小，却完整覆盖了从客户端授权到服务端解密的关键链路，适合正在搭建用户系统、需要打通登录与手机号绑定功能的中初级开发者对照学习。目前已有1180人学习下载，可帮助读者快速理解session_key与加密数据的使用方式，减少在接口调用与解密环节的试错成本，并作为项目集成时的基础代码骨架。
1. 小程序获取手机号：从加密数据到原文件落地的完整链路
很多开发者第一次做小程序获取手机号时，都会卡在同一个地方：前端getPhoneNumber回调里拿到的是encryptedData和iv，后端解密出来是一串 JSON，但业务真正要的是一份能归档、能审计、能二次核验的「原文件」。这个标题里的「原文件」，指的正是手机号获取过程中产生的原始加密数据、解密后的明文结构，以及服务端落盘的那份可追溯记录。它解决的不是「怎么弹授权框」这种入门问题，而是「拿到手机号之后，怎么把原始凭证安全地存下来、怎么在需要时还原、怎么避免重复解密和越权访问」。适合已经跑通基础授权、准备把手机号能力接入正式业务系统的后端和全栈开发者。下面按「先立住原理、再动手复现、最后讲坑」的顺序拆开讲。
2. 手机号获取的三段式链路：授权、解密、落盘
2.1 为什么不能只存解密后的手机号
常见做法是前端拿到code或encryptedData后直接丢给后端，后端解密完把手机号写进用户表就结束了。这个流程能跑通，但埋了两个雷。第一，手机号是敏感个人信息，一旦数据库泄露，明文手机号直接暴露；第二，平台侧的手机号可能变更或解绑，如果只存最终值，后续无法核验「这个号码当时确实是通过授权拿到的」。所以「原文件」思路的核心是：把加密数据、初始向量、解密时间、会话标识一起落盘，手机号本身可以加密存储或哈希索引，原始凭证单独归档。这样既满足审计要求，又能在出现争议时还原完整链路。
2.2 服务端解密的最小可用实现
平台提供的手机号获取接口，典型流程是前端调用getPhoneNumber，回调里返回encryptedData、iv，配合登录态拿到的session_key在服务端做 AES-128-CBC 解密。下面是一段 Node.js 的最小实现，重点看参数来源和落盘结构。
const crypto = require('crypto'); const fs = require('fs'); const path = require('path'); // 解密手机号：sessionKey 来自登录态换取，encryptedData 和 iv 来自前端回调 function decryptPhone(sessionKey, encryptedData, iv) { // 三个参数都必须是 base64 字符串，缺一不可 const key = Buffer.from(sessionKey, 'base64'); const data = Buffer.from(encryptedData, 'base64'); const ivBuf = Buffer.from(iv, 'base64'); // 算法固定为 aes-128-cbc，padding 用 pkcs7 const decipher = crypto.createDecipheriv('aes-128-cbc', key, ivBuf); decipher.setAutoPadding(true); let decoded = decipher.update(data, null, 'utf8'); decoded += decipher.final('utf8'); // 解密结果是 JSON 字符串，包含 phoneNumber、purePhoneNumber、countryCode return JSON.parse(decoded); } // 落盘原文件：把加密数据和解密结果分开存，便于审计 function saveRawRecord(userId, encryptedData, iv, decrypted) { const record = { userId, encryptedData, // 原始加密串，保留 iv, // 初始向量，保留 decryptedAt: new Date().toISOString(), phoneNumber: decrypted.phoneNumber, purePhoneNumber: decrypted.purePhoneNumber, countryCode: decrypted.countryCode }; const dir = path.join(__dirname, 'raw_phone_records'); if (!fs.existsSync(dir)) fs.mkdirSync(dir, { recursive: true }); // 文件名用 userId + 时间戳，避免覆盖 const file = path.join(dir, `${userId}_${Date.now()}.json`); fs.writeFileSync(file, JSON.stringify(record, null, 2), 'utf8'); return file; }这段代码里，sessionKey必须来自服务端用code换取的登录态，不能由前端传入，否则等于把解密钥匙交给了客户端。encryptedData和iv是前端回调原样透传的，服务端不要做任何转码。落盘时把加密串和明文分开字段存，是为了后续如果要做数据脱敏，可以直接删掉明文字段而保留加密凭证。参数上唯一容易翻车的是sessionKey过期，它和登录态绑定，过期后解密会直接抛错，所以解密动作要放在登录态有效期内完成。
2.3 原文件的目录结构与字段约定
如果业务量不大，单文件落盘够用；一旦每天有几千次获取，就需要按日期分目录，避免单目录文件过多导致fs操作变慢。我一般会按年/月/日三级目录组织，文件名用userId_hash加时间戳，避免用户 ID 直接暴露在文件名里。字段上除了上面那几个，还会补一个source字段标记来源场景，比如「下单页」「个人中心」，方便后续排查是哪次授权出了问题。这个结构不复杂，但一定要在项目初期定好，后期改目录结构意味着历史文件要迁移，成本很高。
3. 把原文件落盘做成可复用的服务模块
3.1 解密与落盘的职责拆分
把解密和落盘写在一个函数里，短期看省事，长期看是维护灾难。解密逻辑依赖平台接口的加密方式，落盘逻辑依赖存储方案，两者变更频率完全不同。我一般拆成两个模块：phoneDecrypt只负责把加密串变成结构化对象，rawRecordStore只负责把对象写到磁盘或对象存储。中间用一个PhoneRecord数据结构衔接。这样如果以后要换成云存储，只改rawRecordStore，解密模块完全不动。下面是一个拆分后的目录示意和核心接口。
// phoneDecrypt.js function decryptPhone(sessionKey, encryptedData, iv) { // 省略具体解密实现，返回统一结构 return { phoneNumber: '...', purePhoneNumber: '...', countryCode: '86', watermark: { timestamp: 0, appid: '...' } }; } // rawRecordStore.js function persistRecord(userId, source, encryptedData, iv, decrypted) { // 只负责落盘，不关心解密怎么来的 const record = { userId, source, encryptedData, iv, decrypted, createdAt: Date.now() }; // 写入逻辑省略，返回文件路径或存储 key return '/raw/2025/01/01/xxx.json'; }拆分的收益在排查问题时特别明显。有一次线上反馈「手机号解密失败」，我只看phoneDecrypt的日志就能定位是sessionKey过期还是encryptedData被前端截断，不用在一大坨代码里翻。参数上，source字段建议用枚举值而不是自由文本，否则后期统计时会出现「下单」「下单页」「订单页」三种写法，清洗起来很痛苦。
3.2 用队列削峰，避免解密阻塞主流程
手机号获取往往发生在用户点击「一键登录」的瞬间，这个请求对响应时间很敏感。如果解密和落盘都在主请求里同步做，磁盘 IO 抖动会直接拖慢登录。我的做法是主流程只做解密拿到手机号，落盘动作丢进内存队列异步执行。队列用简单的数组加setImmediate就能实现，不需要引入重型消息队列。下面是一个最小队列实现。
const queue = []; let flushing = false; function enqueueRecord(task) { queue.push(task); if (!flushing) { flushing = true; setImmediate(flushQueue); } } function flushQueue() { // 每次最多处理 50 条，避免长时间占用事件循环 const batch = queue.splice(0, 50); batch.forEach(task => { try { persistRecord(task.userId, task.source, task.encryptedData, task.iv, task.decrypted); } catch (err) { // 落盘失败不能影响主流程，记录错误日志后丢弃 console.error('raw record persist failed', err.message); } }); if (queue.length > 0) { setImmediate(flushQueue); } else { flushing = false; } }这里的关键参数是每批处理数量。设太大，单次flush占用事件循环过久，影响其他请求；设太小，队列积压时落盘延迟变高。50 是一个在普通云主机上比较稳的值，可以根据磁盘写入速度调整。另外落盘失败只记日志不抛错，因为原文件归档是辅助能力，不能让它反过来阻断用户登录。这个取舍要在代码注释里写清楚，否则后来的人可能会「好心」把错误抛出去。
3.3 原文件的读取与核验接口
落盘不是终点，能读出来核验才有价值。我一般会提供一个内部接口，按userId和时间范围查询原文件，返回加密串和解密结果的对照。这个接口不对外网开放，只给内部审计或客服系统调用。实现上就是遍历目录加 JSON 解析，注意加时间范围限制，避免一次拉取过多文件。下面是一个查询示例。
function queryRecords(userId, startTime, endTime) { const results = []; // 按日期目录遍历，省略目录拼接细节 const files = listFilesByRange(startTime, endTime); files.forEach(file => { const content = JSON.parse(fs.readFileSync(file, 'utf8')); if (content.userId === userId) { results.push({ encryptedData: content.encryptedData, phoneNumber: content.decrypted.phoneNumber, createdAt: content.createdAt }); } }); return results; }查询接口一定要做权限校验和频率限制，原文件里包含加密串和手机号，泄露风险比普通业务数据高。参数上startTime和endTime建议强制必填，且跨度不超过 7 天，防止有人拉全量数据。如果业务对性能要求高，可以在落盘时同步写一份索引到数据库，查询先走索引定位文件路径，再读文件内容，这样比全目录遍历快很多。
4. 避坑与排查：手机号原文件落盘的五个血泪教训
4.1 解密报错「bad decrypt」先查 sessionKey 来源
现象是服务端解密直接抛bad decrypt，前端却显示授权成功。原因九成是sessionKey不是服务端用code换的，而是前端传上来的旧值，或者登录态已经过期。解决方法是把sessionKey的获取严格放在服务端，且解密动作紧跟在登录态换取之后，中间不要插入其他异步操作。如果确实需要延迟解密，就在落盘时先存加密串，等登录态刷新后再补解密，不要硬解。
4.2 encryptedData 被 URL 编码导致解密失败
现象是本地测试正常，上线后偶发解密失败。原因是前端把encryptedData放进了 query 参数，+和/被转义。解决方法是前端透传时用 POST body，或者服务端先做一次decodeURIComponent。更稳妥的做法是在前端拿到回调数据后原样JSON.stringify传给后端，不要做任何拼接。这个坑在跨端框架里尤其常见，因为不同框架对回调数据的处理方式不一样。
4.3 落盘文件权限过宽导致信息泄露
现象是安全扫描报告指出原文件目录可被其他进程读取。原因是fs.writeFileSync默认权限跟随系统 umask，可能生成 644 甚至 666 的文件。解决方法是在创建目录和文件时显式指定权限，目录用 700，文件用 600。如果部署在容器里，还要确认挂载卷的权限继承是否正确。原文件里虽然有加密串，但明文手机号也在里面，权限必须收紧。
4.4 时间戳精度不够导致文件覆盖
现象是同一用户短时间内多次获取手机号，原文件只剩最后一条。原因是文件名用了秒级时间戳，同一秒内多次写入会覆盖。解决方法是文件名加上随机后缀或自增序列，或者直接用毫秒级时间戳加进程 ID。更彻底的做法是落盘前检查文件是否存在，存在就追加序号。这个坑在压测时最容易暴露，因为压测会集中触发获取动作。
4.5 忘记处理 watermark 校验导致数据来源存疑
现象是审计时无法确认某条手机号记录是否真的来自平台授权。原因是解密结果里的watermark字段被丢弃了，没有落盘。解决方法是把watermark里的timestamp和appid一起存进原文件，核验时比对appid是否与当前应用一致，timestamp是否在合理时间窗口内。这个字段平时用不到，但一旦出现数据争议，它就是唯一的来源凭证。
5. 进阶：把原文件做成可回溯的审计资产
原文件落盘做到上面这一步，已经能应付大部分业务场景。但如果想让它真正成为审计资产，还需要补两个能力：一是定期归档，把超过一定时间的原文件从热存储转到冷存储，降低主存储压力；二是做完整性校验，给每个原文件算一个哈希值，存到独立的校验表里，读取时比对哈希，防止文件被篡改。哈希用 SHA-256 就够，计算时机放在落盘之后、返回路径之前。
const crypto = require('crypto'); function calcFileHash(filePath) { const content = fs.readFileSync(filePath); return crypto.createHash('sha256').update(content).digest('hex'); } // 落盘后立即算哈希，存入校验表 const filePath = persistRecord(userId, source, encryptedData, iv, decrypted); const hash = calcFileHash(filePath); saveHashIndex(userId, filePath, hash);校验表建议放在独立数据库或独立表里，和业务数据隔离。读取原文件时先查哈希，再比对文件内容，不一致就告警。这个机制在平时是冗余的，但一旦出现磁盘故障或人为误操作，它能帮你快速定位哪些文件不可信。
还有一个容易被忽略的点是原文件的清理策略。手机号属于敏感信息，不能无限期保留。我一般会按业务合规要求设置保留期限，到期后自动删除明文部分，只保留加密串和哈希。删除动作也要记日志，形成「谁在什么时候删了哪些文件」的完整记录。这套机制搭起来不复杂，但需要在项目初期就规划好，后期补会涉及历史数据迁移和合规审查，成本高很多。
我自己在这个方向上踩过最深的一个坑，是早期图省事把解密和落盘写在一个函数里，结果后来平台加密方式调整，我改解密逻辑时不小心把落盘的文件名规则也改了，导致历史文件和新文件混在一起，排查了整整一个下午。从那以后，凡是涉及原文件的操作，我都坚持「解密归解密、落盘归落盘、校验归校验」三层分离，每层只做一件事。希望帮到你。
本文还有配套的精品资源，点击获取
