这次我们来看一个开源零代码平台NocoBase。很多人搭建内部系统、管理后台、业务工具第一反应是买商业 SaaS 或者请人定制开发。实际上如果你只需要在浏览器里定义数据表、拖拽出页面、设置权限然后有一个还能对外开放 API 的后端服务NocoBase 会比传统开发快很多。这篇是 NocoBase 系列教程的第 2 篇。上一篇主要讲了 NocoBase 的整体定位、模块组成和它区别于其他零代码平台的特点。这篇直接进入正题从零开始安装部署然后用一个“博客系统”作为真实案例把数据表设计、页面配置、权限管理、API 调用和批量操作全部跑一遍。看完之后你就能判断这个开源零代码平台适不适合接到自己的项目里。先给结论NocoBase 是一个可私有化部署的开源零代码平台前后端分离核心能力是“数据模型 区块化页面 角色权限 RESTful API”。它不像很多国外低代码平台那样强制连云端也没有把功能锁在商业版里。你要做的只是准备一台有 Docker 的服务器或开发机然后把服务跑起来剩下的工作在浏览器里完成。整个教程我会用 Linux Docker Compose 的方式部署并且用“文章管理”这个小博客案例带你走通从建表到发布的完整链路。1. 核心能力速览在开始安装之前先把 NocoBase 的关键信息放在一张表里方便你判断是否值得继续往下看。能力项说明项目类型开源零代码 / 低代码应用搭建平台部署方式Docker Compose、源码运行更推荐 Docker 方式数据库支持支持 PostgreSQL、MySQL、SQLite 等主流关系型数据库主要功能数据表管理、页面区块拖拽、角色权限控制、工作流配置、RESTful API是否需要写前端代码不需要页面通过可视化配置完成后端可通过插件扩展API 能力内置 RESTful API集合查询、创建、更新、删除均有标准接口批量任务可通过 API 批量写入数据也可结合工作流自动处理支持平台Linux 服务器、Windows / macOS 开发机只要有 Docker 环境即可启动方式命令行 docker compose 启动后通过浏览器访问适合场景内部管理系统、业务数据平台、内容管理后台、项目协同工具这里要特别说明一个点NocoBase 的“零代码”不等于“空壳”。它的重点是把数据模型和页面交互做成可视化操作让非开发人员也能搭出可用的管理系统。但与此同时它保留了插件机制和标准 API开发人员拿到手之后依然可以二次扩展。对团队来说这意味着业务人员可以自己调整字段和布局技术人员专注于插件、权限和集成逻辑。2. 适用场景与使用边界NocoBase 最适合的场景是“有一定数据关系、需要多人协作、需要后台管理的内部系统”。举几个常见例子内容管理后台文章、标签、分类、作者审核管理。进销存与订单管理商品表、订单表、库存表、客户表之间的关联。项目协同工具项目、任务、负责人、里程碑、日志表。运营数据平台线索表、跟进记录、报表看板。它的优势在于当业务字段和页面布局频繁调整时你不需要每次都改代码重新发布。管理员直接在页面上加一个字段、拖一个报表区块就能在几分钟内看到新版本。但也要清楚边界。NocoBase 不适合用来做高并发 C 端应用也不适合实现极其复杂的业务逻辑和前端交互相。比如你要做一个给海量用户实时使用的社交平台或者做一个强交互的数据可视化大屏这些场景用原生开发或专业前端框架会更好。零代码平台的定位是“快速搭建业务后台和管理工具”而不是“替代所有编程开发”。另外在使用边界上还要注意合规和授权问题。因为是私有化部署数据存放在你自己的服务器中你需要自行负责数据备份、访问权限和隐私保护。如果系统里包含员工信息、客户信息或版权内容务必做好角色权限最小化配置同时在对外访问时加上 HTTPS 和访问限制。3. 部署前需要明确几个概念安装 NocoBase 之前建议你先理解几个核心概念后面操作时不会懵。第一个是“数据表”。NocoBase 里的数据表对应数据库中的一张表但你可以直接在后台页面中创建不需要手写 SQL。每一张表可以配置字段字段类型包括单行文本、多行文本、数字、日期、单选、多选、关联、附件、JSON 等。第二个是“区块”。区块是页面上的可视化组件比如表格区块、表单区块、详情区块、日历区块、图表区块。你可以把一个数据表拖到页面中配置成列表展示也可以放一个表单区块用于新增或编辑记录。第三个是“角色权限”。NocoBase 内置了权限系统可以创建不同角色比如管理员、编辑、访客。每个角色可以控制某个数据表的查看、创建、更新、删除权限甚至可以做字段级别的权限控制。最后一个概念是“数据源”。默认情况下你在 NocoBase 里创建的数据表会存在它自己的主数据库中。它还支持接入外部数据源也就是说你能把已有的业务数据库作为 NocoBase 的数据源来配置页面。这个功能对老系统改造很有价值不过本次教程先用默认主数据库就够了。4. 环境准备与前置条件本次安装推荐使用 Docker Compose 方式因为它把 NocoBase 的后端、前端打包在一个容器里把数据库拆到另一个容器中结构清晰、卸载方便。你需要准备以下环境一台 Linux 服务器或者本地 Linux / macOS 开发机。Windows 用户建议使用 WSL2。安装 Docker 和 Docker Compose 插件。规划一个空闲端口教程里使用 13000 作为演示端口也可以按需修改。如果你有域名建议提前把域名解析到服务器 IP后续配置 HTTPS 更方便。没有域名就直接用 IP 访问。确认 Docker 环境是否正常可以先执行两条命令docker --version docker compose version如果版本命令都能正常输出说明 Docker 环境已经就绪。接下来确认磁盘空间。NocoBase 的镜像加上数据库初始化数据预留 10G 以上磁盘空间会更从容生产环境请根据业务数据量另行评估。5. NocoBase 安装部署与启动这里有两条安装路径。官方推荐的是 Docker Compose 方式适合绝大多数人源码方式适合需要深度定制插件或调试后端逻辑的开发者。这里重点讲 Docker Compose。5.1 使用官方仓库的 Docker 模板创建一个项目目录然后从 GitHub 拉取 NocoBase 官方仓库仓库中的 docker 目录内自带编排模板mkdir -p ~/nocobase-demo cd ~/nocobase-demo git clone https://github.com/nocobase/nocobase.git cd nocobase/docker cp .env.example .env编辑.env文件重点确认几个配置项。如果你的服务器端口 13000 被占用可以把APP_PORT改成其他端口。数据库相关配置可以先用默认值生产环境建议把密码改成强密码# 应用端口 APP_PORT13000 # 数据库类型postgres / mysql / sqlite DB_DIALECTpostgres DB_HOSTdb DB_PORT5432 DB_DATABASEnocobase DB_USERnocobase DB_PASSWORDnocobase保存后启动docker compose up -d首次启动会拉取 NocoBase 镜像和数据库镜像耗时取决于网络情况。看到容器状态为 running 后说明服务已经起来了。5.2 自定义 docker-compose.yml 方式如果你不想克隆整个源码仓库也可以直接写一个精简的docker-compose.yml。下面的配置是一个通用模板实际部署时请以 NocoBase 官网最新文档为准必要时替换镜像标签和数据库版本services: app: image: nocobase/nocobase:latest ports: - 13000:80 environment: - APP_KEYplease-change-to-your-own-key - DB_DIALECTpostgres - DB_HOSTdb - DB_PORT5432 - DB_DATABASEnocobase - DB_USERnocobase - DB_PASSWORDnocobase volumes: - ./storage:/app/nocobase/storage depends_on: - db restart: always db: image: postgres:16 environment: - POSTGRES_DBnocobase - POSTGRES_USERnocobase - POSTGRES_PASSWORDnocobase volumes: - ./storage/db:/var/lib/postgresql/data restart: always在这个配置中./storage目录会同时存放 NocoBase 的附件、备份文件和数据库数据。最核心的一个环境变量是APP_KEY它是应用密钥生产环境一定要改成随机长字符串否则会话和令牌存在安全风险。DB_DIALECTpostgres表示使用 PostgreSQL 数据库。如果你更熟悉 MySQL也可以把DB_DIALECT改成mysql并调整db服务的镜像和数据库连接变量。启动命令同样是docker compose up -d5.3 检查启动日志启动之后可以查看容器日志确保没有报错docker compose logs -f app如果日志中出现了类似“Application is running”或“Web server started”的提示说明应用已经启动。此时访问http://服务器IP:13000如果是在本地开发机上部署访问http://localhost:13000浏览器打开后应该会进入 NocoBase 的初始化安装界面。6. 初始化创建管理员账号与系统设置首次访问 NocoBase不会直接看到功能页面而是先进入安装向导。这一步需要你创建一个管理员账号也就是之后登录后台用的账号密码。页面上的关键字段通常包括管理员邮箱、密码、确认密码以及系统标题等。填写完成后点击安装或初始化按钮系统会自动创建数据库表结构并初始化基础数据。需要注意几个细节管理员邮箱建议使用你日常可访问的邮箱密码不要使用弱口令。如果初始化过程中卡住优先检查docker compose logs app的输出。最常见的问题是数据库连接失败比如DB_PASSWORD和数据库容器密码不一致。初始化完成后页面会跳转到登录界面。输入刚才创建的管理员邮箱和密码就能进入 NocoBase 后台。登录成功后你会看到左侧的菜单区、顶部的工具栏和中间的内容区。默认情况下左侧可能只有“UI 编辑器”和“设置”等少量菜单。这里不要着急后面我们按博客案例一步步搭建。7. 博客案例从零搭建一个内容管理后台这个案例的目标是搭建一个简单的博客管理后台能实现文章发布、列表展示、状态管理和后台查看。我们用 NocoBase 一个早上就能搭完不需要写任何前端代码。7.1 创建“文章”数据表进入后台后先创建业务数据表。点击顶部或左侧的“数据表管理”入口新建一个数据表命名为articles中文名称可以写成“文章”。然后为这张表添加字段先保持最小可用字段名字段类型说明title单行文本文章标题必填content多行文本 / 富文本文章正文status单选可选值草稿、已发布published_at日期发布时间views数字浏览量默认值 0在 NocoBase 的字段配置界面中可以直接添加这些字段。选择“单行文本”时可以勾选“必填”约束选择“单选”时手动录入“草稿”和“已发布”两个选项选择“数字”时可以设置默认值0。保存数据表后你可以在“数据表管理”中看到这张表的所有字段。如果之后发现字段不够直接在表结构上新增字段即可不需要进行任何数据库迁移操作。7.2 配置后台菜单页面数据表创建好之后回到页面管理把左侧菜单和页面区块配置起来。这里目标是做一个“文章列表页”用来展示所有文章记录。操作步骤如下新建一个菜单项“文章管理”。进入该菜单的编辑器模式。从数据区块中选择“表格区块”数据表选择articles。把表格区块拖入页面主体区域。在表格区块的字段设置中选择显示 title、status、published_at、views 等字段。保存页面后左侧菜单就会出现“文章管理”点击之后就能看到当前数据表里的文章列表。因为还没有数据表格是空的此时可以顺手测试新增记录在页面右上角添加“创建表单”按钮或直接配置一个“创建表单”区块。填上标题、正文、状态等字段。提交后刷新列表看记录是否出现在表格中。这一步能验证最常见的“新增 列表展示”链路。7.3 配置访客与编辑角色博客场景里通常有两种角色一种是维护内容的编辑一种是只需要看内容的访客。NocoBase 的权限体系可以这样配置。在“设置 - 角色与权限”中默认有管理员角色。管理员拥有所有权限不需要额外配置。然后新建一个“编辑”角色授予articles表的查看、创建、更新、删除权限新建一个“访客”角色只授予查看权限。如果希望访客只能看到“已发布”的文章可以进一步设置数据范围。数据范围条件选择status等于已发布。这样不同角色登录后看到的列表内容是不同的。当然实际项目中为访客创建登录账号的场景比较少见更多时候你可能会通过 API 对外提供文章列表接口然后在访客权限中做好数据隔离即可。7.4 添加标签表并建立关联现在把案例稍微升级一下给文章加上“标签”能力。先新建一张tags表字段只需要一个name单行文本。然后在articles表中增加一个“关联字段”类型选择“多对多”关联到tags表示一篇文章可以有多个标签一个标签也可以属于多篇文章。保存后在文章表单里你就能看到“标签”选择控件可以直接勾选已有标签。这个案例可以很好地证明 NocoBase 的关系字段能力。对后台系统来说订单和客户、项目和成员之间大量存在这种关联关系。用零代码平台搭建时不需要写外键和联表查询配置界面里点几下就完成了。7.5 测试完整发布流程完成以上步骤后建议完整跑一遍博客发布的流程使用管理员账号登录后台。进入“文章管理”页面点击新建文章。填写标题、正文选择状态为“草稿”。提交后确认列表中出现一条草稿记录。再次编辑这条记录把状态改成“已发布”设置发布时间。刷新列表确认记录状态和发布时间都已更新。如果每一步都顺利说明这个博客案例的核心链路已经跑通。接下来可以把这些数据通过 API 暴露给外部访问。8. 接口 API 调用与批量操作NocoBase 自带 RESTful API这是它作为“后端平台”非常关键的亮点。页面上的所有操作底层都可以通过 API 完成。下面给出通用调用方式和示例具体路径和字段名请以实际部署后系统内的 API 文档为准。8.1 查看 API 文档部署完成后可以在 NocoBase 后台找到 API 文档入口里面会列出当前所有集合的接口。API 路径通常类似GET /api/articles:list POST /api/articles:create PUT /api/articles:update DELETE /api/articles:destroy这里的articles对应你创建的数据表名。因为articles是多对多关联了tags所以创建文章时你还可以在请求体中带上标签关联参数。8.2 curl 调用示例先用管理员账号登录获取访问令牌。登录接口通常是 POST 请求提交邮箱和密码实际字段名以 API 文档为准curl -X POST http://127.0.0.1:13000/api/auth/signin \ -H Content-Type: application/json \ -d { email: adminexample.com, password: your-password }登录成功后会返回一个 token。之后请求业务接口时在请求头里带上这个 tokencurl -X POST http://127.0.0.1:13000/api/articles:create \ -H Authorization: Bearer TOKEN \ -H Content-Type: application/json \ -d { title: NocoBase 博客案例, content: 这是一篇通过 API 创建的文章。, status: 已发布 }创建成功之后再调用列表接口确认数据已经写入curl http://127.0.0.1:13000/api/articles:list?pageSize10page1 \ -H Authorization: Bearer TOKEN如果返回的 JSON 中包含刚才创建的文章记录说明 API 链路是通的。8.3 Python 批量任务示例后端集成的典型场景是批量导入数据。比如你有一批历史博客文章需要迁移到新系统可以用 Python 脚本调用 API把文章批量写入。下面给出一个通用模板你需要根据实际接口路径和字段名调整import requests BASE_URL http://127.0.0.1:13000/api TOKEN your-token headers { Authorization: fBearer {TOKEN}, Content-Type: application/json } articles [ {title: 文章标题1, content: 正文1, status: 已发布}, {title: 文章标题2, content: 正文2, status: 草稿}, {title: 文章标题3, content: 正文3, status: 已发布} ] for article in articles: resp requests.post( f{BASE_URL}/articles:create, jsonarticle, headersheaders, timeout30 ) if resp.status_code 200: print(f创建成功: {article[title]}) else: print(f创建失败: {article[title]}, {resp.text})如果你每天都有大量新内容要写入可以把这个脚本挂到定时任务里或者结合 NocoBase 的工作流插件在表单提交后自动触发后续处理。8.4 批量更新与分批处理批量导入几百条数据时不要一次性把所有记录上传。更稳妥的做法是分批处理每批 50 条或 100 条。写入前先调用列表接口查询是否已存在相同标题避免重复导入。对失败的请求要捕获异常并记录到日志中方便后续重试。批量操作的另一个常用场景是批量更新状态。比如把所有“草稿”文章统一改为“已发布”可以先用列表接口查出符合条件的记录 id再逐条调用更新接口。也可以在页面表格中先筛选然后选择多条记录进行批量操作NocoBase 页面本身就支持这个能力。9. 资源占用与性能观察NocoBase 部署后资源占用需要以自己的服务器环境为准。这里重点讲观察方法和影响性能的因素而不是给出某个固定数值。先看 Docker 容器状态docker ps docker statsdocker stats会实时显示每个容器的 CPU、内存和网络占用。观察时建议分两个维度看空闲状态下的基础占用以及业务操作时的峰值占用。如果你同时在 NocoBase 后台编辑页面、批量导入数据内存占用会明显上升。影响 NocoBase 性能的主要因素有几个数据库类型和配置。PostgreSQL 在复杂查询和并发场景下表现更稳定。单表数据量。当文章表、日志表数据量达到百万级后列表查询会变慢需要合理使用筛选条件和数据库索引。附件和文件数量。NocoBase 支持附件上传附件会存储在 storage 目录中。附件过多会影响磁盘空间建议定期清理。并发访问量。如果对外提供 API 服务需要考虑网关层和容器资源的扩展。对于内部管理系统常规并发量下不需要额外调优。如果发现容器内存长期过高可以先检查是不是附件读取或日志输出过大。给 Docker 容器设置资源限制也是一种办法在docker-compose.yml中为服务配置 mem_limit避免单个容器耗尽整台服务器内存。10. 常见问题与排查方法实际操作中大多数人会遇到的问题集中在安装、登录和数据库连接上。这里整理成表格方便你快速定位。问题现象可能原因排查方式解决方案浏览器打开页面一直转圈或显示 502容器未完全启动 / 端口映射错误查看docker compose logs app等待容器健康后刷新确认APP_PORT映射初始化安装时提示数据库连接失败DB_PASSWORD与数据库配置不一致检查.env和docker-compose.yml中数据库变量统一数据库密码后重新启动登录后看不到数据表管理入口当前角色权限不足确认使用的是管理员账号用管理员账号登录或在权限中开放菜单创建数据表后页面还是空白页面未添加区块进入编辑器模式添加对应数据表区块从数据区块中拖动表格或表单到页面修改.env后配置不生效容器未重新创建执行docker compose up -d看看是否重建使用docker compose up -d --force-recreate重建调用 API 返回 401token 缺失或过期检查请求头中 Authorization 字段重新登录获取 token上传附件失败或文件过大Nginx 或网关上传大小限制查看网关日志提高 client_max_body_size或调整附件限制容器重启后数据丢失数据库未挂载 volume检查docker-compose.yml是否配置了数据卷为 db 服务配置 volume数据落在宿主机页面操作后列表不刷新浏览器缓存或区块缓存强制刷新页面清除缓存后重新登录如果遇到不在表格里的问题第一步永远是看日志docker compose logs -f app docker compose logs -f db日志里通常会有明确报错。零代码平台的问题大多集中在环境变量配置和网络端口上很少需要深入代码调试。11. 最佳实践与使用建议把 NocoBase 用到生产环境之前建议先建立一套自己的使用规范避免系统越用越乱。第一数据表命名从一开始就要规范。数据表名使用小写英文字母和下划线业务名称写在中文备注里。比如articles表中文名“文章”tags表中文名“标签”。一旦系统里几十张表之后没有规范命名会很难维护。第二字段权限和角色权限要最小化。能只读就不开放编辑能指定数据范围就不给全部数据。NocoBase 支持字段级权限比如访客可以看到文章标题但不能看到文章编辑人的内部备注。这个能力在生产环境非常实用。第三把storage目录纳入备份计划。NocoBase 的附件、上传文件、数据库 volume 都在这个目录下。建议每天定时打包备份到异地或者至少使用云磁盘快照。第四环境区分。开发环境、测试环境、生产环境建议分开部署。不要在生产环境里直接做页面布局调整。NocoBase 的页面配置是存在数据库里的开发环境改完可以导出备份再恢复到测试环境验证。第五对外暴露服务前先做安全加固。如果你要通过外网访问管理后台务必加 HTTPS更换默认端口设置强密码。如果 API 只给内部系统调用可以在网关层限制来源 IP减少不必要的攻击面。第六注意数据合规。如果系统涉及用户隐私数据要严格遵守网络安全和个人信息保护相关要求。不要随意导出含个人信息的表格也不要授权给无关人员访问。涉及版权素材时确认素材来源合法。12. 总结与下一步NocoBase 这个开源零代码平台最值得尝试的点是“数据表、页面区块、权限、API”闭环非常完整。你不需要写前端代码就能做出一个可用的业务后台需要数据集成时RESTful API 又给了很大的自由度。这篇教程建议你最先验证三件事第一用 Docker Compose 正常启动并创建管理员账号第二创建文章表和标签表并在页面中配置表格区块第三调用 API 创建一个新记录并查询成功。如果这三步都能完成说明你已经可以把 NocoBase 当作一个落地工具来使用了。最容易踩的坑集中在数据库连接配置和容器数据持久化上。数据库密码不一致会导致初始化失败数据库容器没有挂载 volume 会导致重启后数据丢失。安装时不要跳过这些细节生产环境一定要确认 storage 和数据库数据卷都落在宿主机磁盘上。后续可以继续扩展的方向包括接入外部业务数据源把已有的 MySQL 数据库接到 NocoBase 上配置页面使用工作流插件实现审批、消息通知和定时任务基于现有业务表构建更多图表看板让管理层直接看到关键指标。也可以进一步研究 NocoBase 的插件机制开发自己的业务插件。这篇到这里NocoBase 安装和博客案例已经全部跑通。下一篇可以聚焦“数据源接入与企业内部系统迁移”把零代码平台真正用到一个接近生产环境的项目中去。建议收藏备用后面部署和排错时可以直接翻出来对照。