WeDrive 项目介绍：让微信文件少绕几步进 OneDrive

WeDrive 要解决的问题很具体：微信里的文件想转存到 OneDrive，步骤太绕。

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

每一步都不难。

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

所以 WeDrive 的目标也很清楚：让用户在微信里直接连接自己的 OneDrive，完成浏览、上传、下载和基础文件管理，尽量少切几个 App，少绕几步。

它不是另一个网盘，也不想替代 OneDrive。它更像一个“微信里的 OneDrive 文件管理器”。

现阶段的问题是什么

这个需求背后有几个具体问题。

第一，微信文件和云盘之间没有顺手的桥。

微信是很多文件流转的入口，但 OneDrive 才是很多人的长期存储位置。入口和归档位置不在一起，用户就只能手动搬运。

第二，移动端文件转存流程太碎。

下载、打开 App、选目录、上传、等待、确认，每一步都不复杂，但合起来很打断人。

第三，微信小程序的能力和限制并存。

小程序可以选择聊天文件，这很好；但个人主体小程序、OAuth 登录、合法域名、文件上传这些限制，又让事情没法按普通 Web 应用的方式做。

第四，文件类产品天然涉及信任。

用户会关心：文件会不会被平台保存？授权信息存在哪里？服务端到底碰不碰文件内容？这些都必须讲清楚。

所以 WeDrive 不是简单写几个 API 就完事，它要同时处理体验、平台限制和隐私说明。

WeDrive 怎么解决

当前版本的解决方案是：

微信小程序选择文件 / 浏览目录
        ↓
WeDrive 后端处理授权、目录、上传、下载
        ↓
Microsoft Graph 操作用户自己的 OneDrive
        ↓
文件仍然存放在用户自己的 Microsoft 账号里

用户第一次连接时，通过 Microsoft Device Code Flow 授权自己的 OneDrive。之后，小程序就可以在用户授权范围内列目录、上传文件、下载文件和做基础管理操作。

当前已经支持这些能力：

能力	当前状态
浏览文件/文件夹	已可用
从微信聊天选择文件上传	已可用
分片上传和失败重试	已可用
下载并在微信里打开	已可用
重命名、删除、移动、复制	已可用
创建文件夹	已可用
图片、TXT、Markdown 预览	已可用
类型筛选、排序、当前目录搜索	已可用
多 OneDrive 账号切换	已可用
容量查看、分享链接	已可用

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

不花哨，但能解决“我想把微信文件放进 OneDrive”这件事。

用了哪些技术手段

WeDrive 当前主要由三部分组成。

1. 微信小程序

小程序负责用户界面和微信侧能力，比如：

• 选择微信聊天文件；
• 展示 OneDrive 目录；
• 触发上传、下载、重命名、移动、复制；
• 展示当前账号和容量；
• 处理隐私授权提示。

它是用户真正接触到的入口。

2. Microsoft Graph API

OneDrive 的文件操作最终都走 Microsoft Graph：

• 获取用户信息；
• 列出目录；
• 创建文件夹；
• 创建上传会话；
• 下载文件；
• 管理文件元数据；
• 刷新 token。

Graph API 本身能力够用，真正麻烦的不在这里。

3. EdgeOne Pages Functions + KV

后端放在 EdgeOne Pages Functions 上，状态放在 EdgeOne KV 里。

它主要负责：

• 获取 Microsoft 设备码；
• 轮询授权结果；
• 保存和刷新 token；
• 管理微信会话和 OneDrive 账号映射；
• 代理上传分片；
• 代理下载文件；
• 处理多账号切换。

对这种轻量工具来说，这个形态刚刚好：不用单独养服务器，也不用为了几个接口背上运维成本。

我现在越来越偏向这种做法：能用边缘函数和 KV 解决的，就先别上服务器。

遇到了哪些问题，最后怎么解决

问题一：个人主体小程序不能走常规 OAuth

一开始我希望像普通网页一样打开 Microsoft 登录页，让用户授权。

但个人主体小程序不能依赖 web-view 做标准 OAuth 跳转。这条路走不通。

最后只能改成 Device Code Flow：

1. 小程序向后端请求设备码；
2. 用户打开 Microsoft 验证页面；
3. 输入小程序显示的授权码；
4. 授权成功后，小程序轮询后端拿结果；
5. 后端把 token 存到 EdgeOne KV；
6. token 过期时后端自动刷新。

这个体验不完美。第一次连接要复制验证码、打开网页、手动授权。

但它是个人主体小程序阶段更现实的解法。

问题二：OneDrive 上传地址是动态域名

我一开始以为小程序可以直接把文件传到 OneDrive。

理想路径是：后端只创建上传会话，小程序拿到 uploadUrl 后直接 PUT 到 OneDrive。这样服务端不用碰文件流量。

但微信小程序正式环境要求请求域名必须提前配置到“合法域名”。OneDrive 上传会话返回的临时地址，可能来自 Microsoft / OneDrive / SharePoint 的不同子域，不能稳定配置。

最后方案只能改成：

1. 小程序只访问 https://wedrive.nmdft.cn；
2. EdgeOne Pages Functions 负责和 Microsoft Graph 通信；
3. 小程序把文件分片传给 EdgeOne；
4. EdgeOne 再把分片转发到 OneDrive 上传地址；
5. 下载时也由 EdgeOne 代理文件流。

这不是最省流量的方案。

但它是这个阶段更能上线的方案。

技术方案经常就是这样：最漂亮的路径，不一定能穿过平台限制。能稳定跑起来，有时候比架构洁癖更重要。

问题三：多账号状态不能糊弄

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

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

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

这里踩过一个坑：账号标识不能太随便。

早期用设备侧生成的 ID 先顶着跑，后来补了 OneDrive profile 校验，把账号和 Microsoft Graph 里的真实用户信息关联起来。否则多账号一多，很容易出现“界面切换了，实际还是旧 token”的混乱。

文件工具最怕的不是功能少，而是账号状态不可信。

当前成果是什么

现在 WeDrive 已经从方案变成了能用的小程序。

它至少证明了几件事：

1. 微信小程序可以通过 Device Code Flow 连接 OneDrive；
2. EdgeOne Functions + KV 可以承接轻量后端和 token 管理；
3. 通过 EdgeOne 代理，可以绕过微信小程序动态上传域名限制；
4. 微信文件转存 OneDrive 这个流程，确实可以少绕几步；
5. 多账号、目录管理、文件预览这些基础体验可以在小程序里跑起来。

它现在还不是成熟产品，但已经不是空壳。

对一个从具体痛点出发的小工具来说，这个阶段的成果是：链路跑通了，核心功能能用了，坑也基本摸清了。

还需要解决什么

WeDrive 现在仍然有不少限制：

• 上传和下载经过 EdgeOne 中转，会消耗 EdgeOne 流量；
• 分片上传用了 base64，请求体会变大；
• 小程序切后台后，大文件上传不一定稳定；
• Device Code Flow 对普通用户偏麻烦；
• 个人主体小程序如果公开推广，审核和体验仍有不确定性；
• 文件类产品需要持续把隐私和数据流向说清楚。

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

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

这已经挺有价值了。

接下来

如果继续推进，我会先看三件事：

1. 大文件上传在真实手机上的稳定性；
2. Device Code Flow 对非技术用户到底有多劝退；
3. EdgeOne 中转流量成本会不会变成硬限制。

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

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