微信文件传 OneDrive，真正难的是平台限制不是上传接口
这个项目一开始想解决的问题很小：微信里收到文件以后，我想更顺手地把它放进 OneDrive，不想每次都手动来回切 App。
我原本以为难点会在上传接口、文件流或者 OneDrive 权限上。真正做下来才发现，最卡人的反而是平台规则：个人主体小程序不能怎么登录、哪些域名能不能直连、文件流到底能不能按我想的路径走。
所以这篇我主要按“问题是什么 / 方案怎么被逼着收敛 / 哪些地方最后只能妥协”来记，而不是把它写成一篇轻松的功能介绍。
一开始看起来很简单
微信小程序有 wx.chooseMessageFile，可以选择聊天里的文件。
Microsoft Graph API 有上传接口，可以把文件传到 OneDrive。
两边一拼，不就完了？
当然没有这么顺。
我是个人主体小程序。微信规定个人主体不能用 web-view 组件。也就是说，小程序里没法直接打开 Microsoft OAuth 授权页面，让用户像普通网页登录那样登录。
传统 OAuth 路线，直接堵死。
这不是代码写得好不好问题，是规则不让你走。
Device Code Flow：丑，但能用
后来想到 OAuth 2.0 里有 Device Code Flow，专门给没有浏览器输入环境的设备用。
流程大概是：
- 小程序向后端请求设备码；
- 用户拿到一串授权码；
- 用户打开 Microsoft 验证页面；
- 输入授权码并同意授权；
- 小程序轮询后端拿授权结果；
- 后端保存 refresh token，后续自动刷新。
这个体验不优雅。
让用户手动输一串字符，换我我也嫌烦。但如果先做自用版，忍一次就够了。
这是这次的第一个取舍：先接受一次性的笨体验，换来个人主体小程序可用。
后端放哪跑？
接下来是后端。
它需要处理 OAuth token 刷新，还要调用 Microsoft Graph API。最开始想过腾讯云函数，但免费额度不合适；租服务器又觉得太重。
最后选择 EdgeOne Pages Functions。
原因很现实：
- 之前博客部署已经用过 EdgeOne；
- 边缘函数够跑这几个接口；
- Edge KV 正好可以存 token；
- 不需要再维护一台服务器；
- 成本暂时是 0 元。
最初设计里，四个接口就够：
| 接口 | 作用 |
|---|---|
| 获取设备码 / 轮询授权 | 完成 Microsoft 登录 |
| 创建上传会话 | 拿到 OneDrive upload URL |
| token 刷新 | 后端自动续期 |
| 删除文件 | 顺手补一个基础管理能力 |
这个方案不复杂，但边界清楚。
当时的一个架构想法
一开始我希望后端尽量不碰文件内容。
理想路径是：后端只负责获取 OneDrive 的 upload URL，小程序拿到 URL 后直接 PUT 到 OneDrive。
这样后端就是一个纯粹的“认证 + 调度”服务，文件流量不经过我。
这个想法很漂亮，也很省。
后来真正做 WeDrive 的时候，才发现微信小程序正式环境还有合法域名限制，OneDrive 上传会话返回的动态域名不一定能直接配置。于是后来的实现改成了 EdgeOne 代理上传分片。
但这篇记录的是当时的方案阶段。现在回头看，这个误判很有价值：纸面上最省流量的方案，不一定能穿过平台规则。
个人号如果公开产品化，会遇到什么
自用版能做，不代表公开产品就顺。
如果想给其他人用，问题会变多：
- Device Code Flow 对普通用户不友好；
- Microsoft 可能显示“未验证应用”警告；
- 个人主体小程序审核存在不确定性；
- 文件类能力天然涉及隐私说明和用户信任；
- 后端代理上传后，流量成本也要重新算。
所以当时最理性的做法不是直接产品化，而是先跑通自用版。
把链路打通，知道每个坑在哪，再决定要不要往公开产品走。
顺便又修了一次凭据
当天半夜还有个插曲。
天天（我们的新 agent）突然不能回复。错误是：Provider authentication failed: Refresh session has been revoked。
Nous 的 OAuth 凭据过期了。
上次小墨也出过一模一样的问题。看来 Nous 的 refresh token 如果一段时间不用，可能会被服务端吊销。
临时解决办法很粗暴：把爪爪的 auth.json 复制过去，重启 gateway，三分钟恢复。
但这不是长期方案。
多人共用一个 Nous 账号的 OAuth 凭据，迟早会出问题。后面要么给每个 agent 独立凭据，要么换更稳定的认证方式。
这是另一个提醒：AI 工作流里，最容易拖后腿的往往不是模型能力，而是凭据、权限、会话这些基础设施。
当时的结论
这次折腾让我对 WeDrive 有了一个更清楚的判断：它技术上可行，但不能一开始就按成熟产品来设计。
更合适的路线是：
- 先做自用版；
- 用 Device Code Flow 跑通授权；
- 用 EdgeOne Functions + KV 承担轻后端；
- 尽量少维护服务器；
- 等真实使用后，再判断要不要处理企业主体、应用验证和公开发布。
小工具最怕的不是“不够完美”。
小工具最怕的是还没证明自己有用，就先背上一整套产品化包袱。