NocoBase 2.2 正式版的重点，不只是继续打磨 V2 页面，而是把 V2 的完整使用路径补齐。随着 /v/ 独立前端入口和新移动端落地，V2 开始具备更加独立、轻量的运行形态；同时，文件访问、评论区块、AI 知识库、工作流以及核心插件也在持续完成 V2 适配。
对于已经主要使用 V2 页面构建应用的团队来说，这个版本更像是一次运行基础设施的完善，而不是单纯的界面升级。升级前需要关注的重点，也从“页面能不能打开”扩展到入口、文件、移动端和插件是否能够完整协同工作。
/v/ 入口意味着什么
传统的版本升级通常集中在页面组件、交互方式或视觉层面。NocoBase 2.2 的变化更接近前端运行环境的调整：V2 页面拥有独立的访问入口，可以通过 /v/ 路径进入。
这种入口分离带来几个实际价值：
- 可以更清晰地区分旧页面与 V2 页面，降低迁移期间的路由混淆。
- 可以围绕 V2 页面单独验证登录、资源加载和插件兼容性。
- 移动端可以复用更轻量的前端入口，而不必把桌面端的全部复杂度带入小屏设备。
- 后续 V2 功能演进拥有更加明确的边界。
这里需要注意，/v/ 是否直接可用、具体页面路径如何生成，仍取决于应用配置和部署方式。下面的命令用于做一组最小化的入口检查，域名和预期状态码需要按实际环境调整。
#!/usr/bin/env bash
set -euo pipefail
BASE_URL="${BASE_URL:-http://localhost:13000}"
check_url() {
local name="$1"
local url="$2"
local status
status="$(curl -L -sS -o /dev/null -w '%{http_code}' "$url")"
printf '%-18s %s -> HTTP %s\n' "$name" "$url" "$status"
case "$status" in
2*|3*) ;;
*)
echo "检查失败：$url" >&2
return 1
;;
esac
}
check_url "主入口" "$BASE_URL/"
check_url "V2 入口" "$BASE_URL/v/"
# 如果应用使用了独立移动端入口，请将路径替换为实际配置。
# check_url "移动端入口" "$BASE_URL/mobile/"
这段脚本适合放在升级后的冒烟测试中。它不能替代浏览器端验证，但可以快速发现反向代理没有转发 /v/、静态资源路径错误或应用没有正常返回响应等问题。
文件访问机制需要重新验证
版本升级涉及文件访问机制时，影响范围通常比文件上传本身更大。文件可能被评论、知识库、业务表单和工作流共同引用，因此需要同时检查上传、读取、权限和历史数据访问。
建议把验证拆成四个动作：
- 上传一个新的测试文件，确认文件记录和实际存储都成功。
- 在 V2 页面中打开文件，确认访问地址、认证状态和响应头符合预期。
- 用无权限用户访问同一文件，确认不会因为新的访问入口而意外暴露。
- 打开升级前创建的历史文件，确认旧数据仍然可用，或已经有明确的迁移策略。
可以用 curl 做一个基础的响应检查。示例中的路径是占位路径，实际使用时替换为应用生成的文件地址，并根据系统认证方式补充 Cookie 或令牌：
BASE_URL="http://localhost:13000"
FILE_PATH="/api/files/your-test-file-id"
curl -i \\
"$BASE_URL$FILE_PATH"
# 带 Bearer Token 的示例
curl -i \\
-H "Authorization: Bearer $NOCobASE_TOKEN" \\
"$BASE_URL$FILE_PATH"
不要只检查 HTTP 200。还要确认返回内容确实是目标文件，不能是登录页、错误 JSON 或代理层的默认页面。对于私有文件，重点检查未认证和低权限用户的响应结果。
评论、知识库与工作流的联动影响
2.2 继续完善评论区块、AI 知识库和工作流等能力的 V2 适配。它们看起来属于不同功能，但在实际应用中经常共享同一条数据链路：业务记录产生内容，评论补充上下文，知识库整理资料，工作流负责触发后续动作。
升级测试不应只打开每个插件的配置页，而应该按照真实业务路径走一遍。例如：
- 在 V2 页面创建一条业务记录。
- 添加评论并确认评论内容、作者和时间正确显示。
- 将附件或业务资料提交给知识库流程，检查文件读取权限。
- 触发一个工作流，确认节点能够读取 V2 页面写入的数据。
- 返回移动端重复关键操作，检查布局和交互是否仍然可用。
如果某个核心插件仍然依赖旧版页面上下文，常见表现可能不是立即报错，而是按钮缺失、字段值为空、评论加载失败或工作流触发条件不成立。因此，插件兼容性需要按业务动作验证，而不是只看“插件已安装”。
一套可执行的升级检查表
对于已经以 V2 页面为主的应用，可以按照以下顺序安排升级：
[ ] 备份数据库、文件存储和应用配置
[ ] 在测试环境确认 /v/ 入口可访问
[ ] 验证桌面端 V2 页面和静态资源加载
[ ] 验证新移动端的登录、列表、详情和提交操作
[ ] 上传新文件并打开历史文件
[ ] 用不同权限账号检查文件访问边界
[ ] 测试评论区块的新增、读取和权限
[ ] 测试 AI 知识库的资料读取与检索链路
[ ] 测试至少一条包含 V2 数据的工作流
[ ] 检查自定义插件和核心插件的页面行为
[ ] 观察日志、错误率和资源请求失败情况
上线时可以先让内部用户或低风险应用使用 2.2，再逐步扩大范围。对于仍依赖旧版页面或大量自定义插件的应用，应该先建立兼容性清单，再决定是否整体切换。
采用建议
NocoBase 2.2 的价值主要体现在 V2 生态逐渐形成闭环：独立入口负责访问边界，移动端扩展使用场景，文件访问机制支撑资源流转，评论、知识库、工作流和核心插件则补齐业务能力。
如果当前应用已经主要使用 V2 页面，2.2 值得进入升级评估范围。但升级判断不应只依据页面是否正常显示，而要覆盖入口路由、文件权限、移动端流程和插件联动。把这些检查纳入发布流水线，后续版本升级会更容易控制风险，也能更早发现那些只有真实业务操作才会暴露的问题。