WeDrive 做出来后，我才知道微信文件进 OneDrive 真正卡在哪

WeDrive 一开始只是个很小的念头：微信里收到文件以后，我想少绕几步，把它放进 OneDrive。

同事发个文档，群里丢个 PDF，或者手机里临时收到一张图片，正常流程通常是：先在微信下载，再打开 OneDrive App，再找目录，再上传，再确认有没有成功。

每一步都不难。

但这种“不难”的小动作，一旦频繁出现，就会变成很烦的重复劳动。

所以 WeDrive 的目标很克制：它不是另一个网盘，也不想替代 OneDrive。它更像一个微信里的 OneDrive 文件管理器，让用户在微信里完成浏览、上传、下载和基础文件管理。

真正做下来我才发现，难点不在 Microsoft Graph API。Graph 的能力足够清楚。更麻烦的是微信小程序的规则、OAuth 授权路径、合法域名限制、上传流量中转，以及文件类产品天然要面对的信任问题。

一开始我以为后端不用碰文件

最初的方案很漂亮。

微信小程序有 wx.chooseMessageFile，可以选择聊天文件。Microsoft Graph 有上传接口，可以把文件传到 OneDrive。后端只负责授权和创建上传会话，然后把 OneDrive 返回的 uploadUrl 给小程序，小程序直接 PUT 文件过去。

理想链路是这样：

微信小程序选择文件
        ↓
后端创建 OneDrive upload session
        ↓
小程序直接上传到 OneDrive 临时地址
        ↓
文件进入用户自己的 OneDrive

这个方案的好处很明显：后端不碰文件流量，成本低，隐私解释也更简单。

但它后来被现实打回来了。

微信小程序正式环境要求请求域名必须提前配置到合法域名。OneDrive 上传会话返回的临时地址并不是一个固定域名，可能来自 Microsoft、OneDrive、SharePoint 的不同子域。你没法把所有动态上传域名都稳定配置进去。

所以最省流量的方案，在平台规则面前走不通。

Device Code Flow：不优雅，但能过个人主体限制

授权也不是普通 Web 应用那套。

我一开始希望在小程序里打开 Microsoft 登录页，让用户授权自己的 OneDrive。可个人主体小程序不能依赖 web-view 走标准 OAuth 跳转，这条路基本堵死。

最后只能用 OAuth 2.0 的 Device Code Flow。

流程是：

1. 小程序向后端请求设备码；
2. 后端向 Microsoft 申请 device code；
3. 小程序显示验证码和验证链接；
4. 用户打开 Microsoft 页面，输入验证码并授权；
5. 小程序轮询后端，等待授权完成；
6. 后端保存 refresh token，之后自动刷新。

这个体验不优雅。第一次连接要复制验证码、打开网页、手动确认。对普通用户来说，它肯定比“一键登录”更劝退。

但它有一个优点：在个人主体小程序阶段，它能跑通。

这是 WeDrive 的第一个取舍：先接受一次性的笨体验，换来链路可用。

最后选择 EdgeOne 代理上传

因为动态上传域名不能直连，后端就不能只做“认证 + 调度”。它必须参与文件流转。

当前链路变成了这样：

微信小程序选择文件 / 浏览目录
        ↓
小程序只访问 wedrive.nmdft.cn
        ↓
EdgeOne Pages Functions 处理授权、目录、上传、下载
        ↓
Microsoft Graph 操作用户自己的 OneDrive
        ↓
文件最终仍存放在用户自己的 Microsoft 账号里

上传时，小程序把文件分片传给 EdgeOne；EdgeOne 再把分片转发到 OneDrive 上传会话地址。下载时也类似，小程序访问固定域名，由 EdgeOne 代理 Graph 下载。

这不是最省流量的架构，但它能穿过微信小程序的合法域名限制。

做小工具经常会遇到这种选择：纸面上最优雅的路径，不一定能上线；能上线的路径，往往要接受一点工程上的不完美。

当前已经做到什么

WeDrive 现在已经不是方案文档，而是一个能用的小程序雏形。

当前能力大致是：

能力	当前状态	说明
Microsoft 授权	已可用	Device Code Flow
浏览 OneDrive 文件/文件夹	已可用	通过 Graph API
微信聊天文件上传	已可用	EdgeOne 代理分片上传
下载并在微信打开	已可用	后端代理文件流
创建文件夹	已可用	基础文件管理
重命名、删除、移动、复制	已可用	覆盖常见管理动作
图片/TXT/Markdown 预览	已可用	先做轻量预览
类型筛选、排序、目录搜索	已可用	小程序内文件管理体验
多 OneDrive 账号切换	已可用	账号状态已独立管理
容量查看、分享链接	已可用	补齐常用信息

说白了，它已经像一个小型 OneDrive 文件管理器。

不花哨，但能解决“微信文件想进 OneDrive”这个具体问题。

多账号状态不能糊弄

一开始我只想着自己用，一个 OneDrive 账号就够了。

做到后面发现，多账号是很自然的需求。很多人会同时有个人 Microsoft 账号和公司账号，也可能一个账号放临时文件，一个账号做归档。

既然 token 已经存在 KV 里，就顺手把账号索引也做了。

这里有个坑：账号标识不能太随便。

早期如果只用设备侧生成的 ID 顶着跑，多账号一多，很容易出现“界面切换了，实际操作还是旧 token”的混乱。文件工具最怕这个，因为一旦账号状态不可信，用户就不敢用。

后来补了 OneDrive profile 校验，把账号和 Microsoft Graph 返回的真实用户信息关联起来。至少要保证界面显示的账号，和后端实际使用的 token 是同一个人。

文件类产品可以功能少，但不能状态糊。

文件类工具必须讲清楚信任边界

WeDrive 还有一个绕不开的问题：服务端到底碰不碰文件？

按现在的实现，上传和下载都会经过 EdgeOne 代理。这意味着服务端会转发文件流，但文件最终存储在用户自己的 OneDrive，不会落到我自己的数据库或网盘里。

这个边界必须讲清楚：

• token 存在 EdgeOne KV，用于刷新 Microsoft 授权；
• 文件内容经过 EdgeOne Functions 中转；
• 文件最终保存在用户自己的 OneDrive；
• 服务端不应该长期保存文件内容；
• 如果未来公开给别人用，要补隐私说明和授权撤销机制。

如果只是我自己用，这些可以先简单处理。只要想公开，就不能含糊。

文件类产品的用户信任成本，比普通工具高很多。你让用户交出云盘授权，就必须解释数据怎么走、哪里存、怎么撤销。

还没解决的问题

WeDrive 能跑，不代表已经适合公开推广。

当前还有几个明显限制：

1. 上传/下载经过 EdgeOne 中转：会消耗流量，成本要看真实使用量；
2. 大文件上传稳定性待验证：小程序切后台、网络波动、分片失败都会影响体验；
3. Device Code Flow 对普通用户偏麻烦：自用能忍，公开产品可能劝退；
4. 个人主体小程序审核不确定：文件管理、云盘授权都需要谨慎说明；
5. 隐私和授权撤销还要补完整：尤其是多账号和 token 管理；
6. EdgeOne Functions 的请求体和超时限制要继续压测。

所以我不会把它包装成“革命性网盘工具”。

它更像一个真实的小工具：从一个具体烦恼出发，绕过平台限制，最后做到“我确实可以少点几下”。

这已经够有价值了。

接下来怎么判断要不要继续

我会先看三件事。

第一，大文件上传在真实手机上的稳定性。小文件能传不说明问题，几十 MB 的文件、弱网、切后台才是真考验。

第二，Device Code Flow 对非技术用户到底有多劝退。如果用户第一次连接就放弃，那后面功能再完整也没用。

第三，EdgeOne 中转流量成本会不会变成硬限制。如果代理上传一旦有人用就开始烧钱，要么改架构，要么明确只做自用/小范围工具。

如果这三件事都能接受，WeDrive 可以继续小范围试用。

如果不行，它至少也完成了一个小工具该完成的任务：把一个烦人的流程往前推了一步，并留下可复用经验——微信小程序授权、OneDrive Graph API、EdgeOne Functions + KV、上传代理、多账号状态管理。

小工具最怕的不是“不够完美”。

小工具最怕的是还没证明自己有用，就先背上一整套产品化包袱。WeDrive 现在的价值，就是在不背太重包袱的前提下，把核心链路跑通了。