hello OpenlistTeam：
因为想试试看serverless版本做得怎么样所以让ai帮忙本地部署了一下，发现问题蛮多的，以下是AI提的issue，请见谅
你好，我在本地部署并排查这个项目时，围绕“新增挂载点”流程遇到了一系列问题。
以下内容尽量基于源码和实际日志整理，不依赖 README。
一、环境与前置情况
我本地是在 Windows 环境下跑的，前端和 Worker/API 分别启动。
项目可以基本跑起来，管理后台也能进入，但“新增挂载点”流程问题较多。
二、初始化与部署阶段的问题
- wrangler.jsonc 是模板配置，不能直接运行
仓库内的 wrangler.jsonc 中包含未填写的占位项，例如：
kv_namespaces[].id = ""
d1_databases[].database_name = ""
d1_databases[].database_id = ""
在这种状态下，Wrangler 会先做配置校验并直接报错，无法正常继续。
- 静态资源目录依赖前置构建
wrangler.jsonc 里配置了：
"assets": {
"directory": "./public",
"binding": "ASSETS"
}
但初次运行时 public 目录并不存在，导致 wrangler dev 直接报错。
也就是说，前端资源需要先构建出来，否则 Worker 端无法正常启动。
- D1 不会自动建表
项目启动后，请求部分后台接口时会直接报：
no such table: users
说明数据库表结构不会自动初始化，必须手动执行 schema.sql。
这一点对首次部署影响较大。
- 首次管理员初始化不是自动完成的
根据源码，管理员账号是通过初始化接口创建的，不是自动生成。
如果没有主动执行初始化流程，即使项目跑起来，也无法直接正常登录使用。
三、管理后台“新增挂载点”页面的问题
主要问题集中在 pages/src/pages/Admin/MountManagement.tsx 对应页面。
- “新增挂载点”弹窗中的多个选择框无法正常使用
我在“新增挂载点”中遇到以下下拉项异常：
驱动类型
代理模式
状态
WebDAV 下的服务商类型
现象包括：
无法展开
点击后抖动
点击后弹窗关闭
看似有值，但无法真正切换
从源码看，这几个字段本身并不是都被业务逻辑故意禁用。
例如：
驱动类型只在编辑模式下禁用
状态没有写 disabled
代理模式仅在部分 proxy_only 驱动下禁用
所以更像是 Modal + antd Select + 内部滚动容器 组合带来的交互问题，而不是单纯的业务限制。
- WebDAV 的“服务商类型”即使显示默认值，也可能提交出不符合预期的 vendor
在实际测试 WebDAV 时，前端页面显示的是类似“通用WebDAV”，但后端日志里实际拿到的是：
vendor: other
后续初始化时失败，说明前端显示和后端实际收到的数据之间，可能存在不一致或未正确映射的问题。
四、前后端字段定义不一致，导致新增挂载直接 400
现象
即使页面里已经选择了驱动类型并填写了挂载路径，后端依然返回：
mount_path 和 driver 不能为空
原因
排查发现，前端提交的数据结构与后端接口要求的不一致。
前端原本提交的是这类字段：
mount_type
drive_conf
cache_time
is_enabled
proxy_mode
但后端创建挂载接口实际要求的是：
driver
addition
cache_expiration
disabled
web_proxy
因此即使前端已经选了驱动，后端依然会认为 driver 为空。
这属于明显的前后端契约不一致问题。
五、WebDAV 实际挂载时的错误
在驱动类型选择为 WebDAV，地址填写为坚果云 WebDAV 地址后，后端日志出现：
WebDAV error: 404 Not Found
ObjectNotFound
One of this location does not exist
日志中能看到类似信息：
vendor: other
address: https://dav.jianguoyun.com/dav/
这说明当前项目是按“通用 WebDAV / other vendor”的逻辑在初始化该地址，而不是按坚果云兼容逻辑处理。
在这种情况下，WebDAV 初始化失败。
六、WebDAV 初始化失败后还可能触发 OOM
在 WebDAV 初始化失败之后，后端还出现了：
JavaScript heap out of memory
这看起来不像第一原因，而更像是：
初始化失败后某段异常处理/重复处理逻辑没有收住
最后把 Node / Worker 运行环境内存打满
也就是说，这里不仅有 WebDAV 初始化失败问题，还可能有失败场景下的资源释放或异常处理问题。
七、目前总结
从本地实际部署和调试来看，这个项目至少存在以下问题：
-
wrangler.jsonc 作为模板存在未填写占位项，不能直接运行
-
前端资源和数据库都需要额外手动初始化，缺少更顺滑的首次运行流程
-
“新增挂载点”页面中多个选择框存在明显交互问题
-
新增挂载时前后端字段定义不一致，直接导致 400
-
WebDAV 在服务商类型 / vendor 映射上可能有问题
-
WebDAV 初始化失败后，后端还可能继续触发 OOM
八、期望
希望能确认并修复以下问题：
统一“新增挂载点”前后端字段定义
修复管理后台新增挂载弹窗中的选择组件交互
明确 WebDAV 服务商类型与后端 vendor 的映射关系
优化 WebDAV 初始化失败后的异常处理，避免进一步 OOM
补充更明确的首次运行初始化说明，或者考虑自动化部分初始化流程
如果需要，我也可以继续补充：
具体复现步骤
关键报错截图
对应源码位置
我本地修改过的临时绕过方案
你要是愿意，我还能顺手再给你写一个更像 GitHub issue 风格的精简版，更短、更适合直接贴。
hello OpenlistTeam：
因为想试试看serverless版本做得怎么样所以让ai帮忙本地部署了一下，发现问题蛮多的，以下是AI提的issue，请见谅
你好，我在本地部署并排查这个项目时，围绕“新增挂载点”流程遇到了一系列问题。
以下内容尽量基于源码和实际日志整理，不依赖 README。
一、环境与前置情况
我本地是在 Windows 环境下跑的，前端和 Worker/API 分别启动。
项目可以基本跑起来，管理后台也能进入，但“新增挂载点”流程问题较多。
二、初始化与部署阶段的问题
仓库内的 wrangler.jsonc 中包含未填写的占位项，例如：
kv_namespaces[].id = ""
d1_databases[].database_name = ""
d1_databases[].database_id = ""
在这种状态下，Wrangler 会先做配置校验并直接报错，无法正常继续。
wrangler.jsonc 里配置了：
"assets": {
"directory": "./public",
"binding": "ASSETS"
}
但初次运行时 public 目录并不存在，导致 wrangler dev 直接报错。
也就是说，前端资源需要先构建出来，否则 Worker 端无法正常启动。
项目启动后，请求部分后台接口时会直接报：
no such table: users
说明数据库表结构不会自动初始化，必须手动执行 schema.sql。
这一点对首次部署影响较大。
根据源码，管理员账号是通过初始化接口创建的，不是自动生成。
如果没有主动执行初始化流程，即使项目跑起来，也无法直接正常登录使用。
三、管理后台“新增挂载点”页面的问题
主要问题集中在 pages/src/pages/Admin/MountManagement.tsx 对应页面。
我在“新增挂载点”中遇到以下下拉项异常：
驱动类型
代理模式
状态
WebDAV 下的服务商类型
现象包括：
无法展开
点击后抖动
点击后弹窗关闭
看似有值，但无法真正切换
从源码看，这几个字段本身并不是都被业务逻辑故意禁用。
例如：
驱动类型只在编辑模式下禁用
状态没有写 disabled
代理模式仅在部分 proxy_only 驱动下禁用
所以更像是 Modal + antd Select + 内部滚动容器 组合带来的交互问题，而不是单纯的业务限制。
在实际测试 WebDAV 时，前端页面显示的是类似“通用WebDAV”，但后端日志里实际拿到的是：
vendor: other
后续初始化时失败，说明前端显示和后端实际收到的数据之间，可能存在不一致或未正确映射的问题。
四、前后端字段定义不一致，导致新增挂载直接 400
现象
即使页面里已经选择了驱动类型并填写了挂载路径，后端依然返回：
mount_path 和 driver 不能为空
原因
排查发现，前端提交的数据结构与后端接口要求的不一致。
前端原本提交的是这类字段：
mount_type
drive_conf
cache_time
is_enabled
proxy_mode
但后端创建挂载接口实际要求的是：
driver
addition
cache_expiration
disabled
web_proxy
因此即使前端已经选了驱动，后端依然会认为 driver 为空。
这属于明显的前后端契约不一致问题。
五、WebDAV 实际挂载时的错误
在驱动类型选择为 WebDAV，地址填写为坚果云 WebDAV 地址后，后端日志出现：
WebDAV error: 404 Not Found
ObjectNotFound
One of this location does not exist
日志中能看到类似信息：
vendor: other
address: https://dav.jianguoyun.com/dav/
这说明当前项目是按“通用 WebDAV / other vendor”的逻辑在初始化该地址，而不是按坚果云兼容逻辑处理。
在这种情况下，WebDAV 初始化失败。
六、WebDAV 初始化失败后还可能触发 OOM
在 WebDAV 初始化失败之后，后端还出现了：
JavaScript heap out of memory
这看起来不像第一原因，而更像是：
初始化失败后某段异常处理/重复处理逻辑没有收住
最后把 Node / Worker 运行环境内存打满
也就是说，这里不仅有 WebDAV 初始化失败问题，还可能有失败场景下的资源释放或异常处理问题。
七、目前总结
从本地实际部署和调试来看，这个项目至少存在以下问题：
wrangler.jsonc 作为模板存在未填写占位项，不能直接运行
前端资源和数据库都需要额外手动初始化，缺少更顺滑的首次运行流程
“新增挂载点”页面中多个选择框存在明显交互问题
新增挂载时前后端字段定义不一致，直接导致 400
WebDAV 在服务商类型 / vendor 映射上可能有问题
WebDAV 初始化失败后，后端还可能继续触发 OOM
八、期望
希望能确认并修复以下问题：
统一“新增挂载点”前后端字段定义
修复管理后台新增挂载弹窗中的选择组件交互
明确 WebDAV 服务商类型与后端 vendor 的映射关系
优化 WebDAV 初始化失败后的异常处理，避免进一步 OOM
补充更明确的首次运行初始化说明，或者考虑自动化部分初始化流程
如果需要，我也可以继续补充：
具体复现步骤
关键报错截图
对应源码位置
我本地修改过的临时绕过方案
你要是愿意，我还能顺手再给你写一个更像 GitHub issue 风格的精简版，更短、更适合直接贴。