当前位置：首页 > news >正文

开源应用平台Budibase：从低代码到企业级自托管部署全解析

news 2026/4/27 5:35:41

1. 项目概述：从“低代码”到“开源应用平台”的认知跃迁

第一次听说Budibase，很多人会下意识地把它归类到“又一个低代码工具”的范畴里。毕竟，市面上打着“拖拽式开发”、“快速构建应用”旗号的产品实在太多了。但当你真正深入使用Budibase，特别是接触到它的开源版本后，你会发现这个标签过于狭隘，甚至有些误导。Budibase的核心，是一个面向开发者和技术团队的、开源的、可自托管的应用构建平台。它解决的痛点，远不止是“让业务人员也能做应用”那么简单。

我最初接触Budibase，是因为团队内部需要快速搭建一个项目管理仪表盘，用来追踪几十个小型项目的进度、工时和风险。当时我们评估了从Excel+Power BI到一些SaaS工具，但要么灵活性不够，要么数据安全有顾虑，要么二次开发成本太高。Budibase的出现，让我们在两天内就搭建出了一个功能完整、数据实时、且能无缝嵌入到现有工作流中的内部应用。更重要的是，整个应用的数据库、后端逻辑和前端界面，都完全运行在我们自己的服务器上，这种“掌控感”是任何SaaS服务都无法提供的。

Budibase的核心价值在于，它用一套非常优雅的架构，将数据库连接、API集成、业务逻辑编排和UI构建这些复杂工作，封装成了可视化、可配置的模块。开发者可以用它像搭积木一样快速构建出CRUD应用、管理后台、数据看板，甚至是带有复杂工作流的业务系统。而它的开源特性，意味着你可以无限制地使用、修改、甚至基于它的代码构建自己的商业化产品。这对于有定制化需求、注重数据主权、或预算有限的技术团队来说，吸引力是巨大的。接下来，我将从设计思路、核心功能、实操部署到深度定制，为你完整拆解这个强大的工具。

2. 核心架构与设计哲学解析

2.1 前后端分离与“构建器-服务器”模型

Budibase的架构设计非常清晰，采用了典型的前后端分离模式，并且将“设计时”和“运行时”彻底分开。整个平台主要由两个核心部分组成：Budibase Builder（构建器）和Budibase Server（服务器）。

Builder（构建器）是一个基于Web的可视化设计工具，也就是你拖拽组件、配置数据源、设计业务逻辑的地方。它本质上是一个单页应用（SPA），运行在你的浏览器里。当你在这里进行设计时，所有的配置信息（比如组件树、数据绑定、自动化流程）都会被实时保存为一个JSON格式的“应用定义”。这个定义文件，就是你的应用的“源代码”。

Server（服务器）则是实际运行你应用的后端服务。它负责提供REST API，处理数据库的CRUD操作，执行你配置的自动化工作流（Automations），并托管最终生成的应用前端。当你从Builder点击“发布”时，Builder会将那个JSON“应用定义”发送给Server，Server会据此动态生成对应的API接口和渲染出前端页面。

这种设计的精妙之处在于关注点分离。Builder专注于提升开发体验，提供强大的可视化能力；Server则专注于性能、安全性和稳定性。更重要的是，这为多环境部署（开发、测试、生产）和版本控制提供了天然支持。你可以将应用定义导出为JSON文件，用Git进行管理，实现应用开发的DevOps流程。

2.2 数据层的抽象：从内部表到外部数据源

数据是任何应用的核心。Budibase在数据层设计上提供了极大的灵活性，抽象出了一个统一的数据模型。你可以使用两种主要类型的数据源：

内部表（Internal Tables）：这是Budibase自带的、基于PostgreSQL或CouchDB的数据库。它非常适合存储应用自身的核心数据，比如用户、订单、任务等。创建内部表非常简单，像在Airtable或Notion里一样，通过UI添加字段（文本、数字、关联、附件等）即可，无需编写任何SQL。Server会自动为你创建对应的数据库表。
外部数据源（External Data Sources）：这是Budibase的杀手级功能之一。它允许你直接连接并操作外部已有的数据库或API，将外部数据“虚拟化”为Budibase应用内的数据表。目前官方支持包括：
- 数据库：PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, MongoDB, CouchDB, S3, Redis, ElasticSearch。
- API：REST API (通过OpenAPI/Swagger定义导入)、Google Sheets、Airtable、Directus等。

当你连接一个外部MySQL数据库后，Budibase会自动读取其表结构，并将其中的表以“只读”或“可读写”模式映射到Builder中。你可以像操作内部表一样，为这些外部表配置视图、设置权限、甚至在其上创建关联关系。这意味着你可以在不迁移数据的前提下，快速为遗留系统构建一个现代化的管理后台或操作门户。例如，直接为公司的老ERP数据库套上一个美观易用的前端界面。

2.3 组件化与可扩展性设计

Budibase的前端界面由“块（Blocks）”和“组件（Components）”构成。块是布局单元（如容器、行、列），组件是功能单元（如表格、表单、图表、按钮）。所有官方组件都是开源的，其代码位于独立的仓库中。

真正的威力在于其插件系统。你可以开发自定义组件和自定义数据源插件。这意味着，如果官方组件不满足你的需求（比如需要一个特殊的图表类型），或者你需要连接一个非常小众的数据库，你可以用JavaScript/React开发自己的插件，然后导入到Budibase中使用。这彻底打开了Budibase的能力边界，使其从一个工具演变成一个平台。

3. 从零开始：部署与第一个应用实战

3.1 选择你的部署方式

Budibase提供了极其灵活的部署选项，这也是开源项目的优势所在。

云托管（Budibase Cloud）：最简单的方式，注册即用。适合个人、小团队快速尝鲜或用于非核心业务。免费版有一定限制。
自托管（Self-Hosted）：这是最推荐、也是最能体现Budibase价值的方式。你可以完全控制所有数据和应用。官方提供了多种自托管方案：
- Docker Compose（推荐）：这是最快捷、最标准的方式。官方提供了一个docker-compose.yaml文件，一键启动所有服务（包括Budibase Server、MinIO对象存储、Redis缓存等）。你只需要准备好一台有Docker环境的Linux服务器（如Ubuntu 20.04+）。
- Kubernetes：对于生产级、高可用的部署，可以使用官方Helm Chart部署到K8s集群。
- DigitalOcean / AWS Marketplace：官方提供了一键部署镜像，进一步简化了在云平台上的部署。

注意：自托管时，Budibase默认使用一个内置的CouchDB实例存储元数据和内部表数据。对于生产环境，强烈建议配置外部PostgreSQL数据库作为主数据库，并配置外部S3兼容存储（如MinIO）用于文件存储，以获得更好的性能和可靠性。

3.2 使用Docker Compose快速部署

假设你有一台Ubuntu服务器，以下是最简化的部署步骤：

环境准备：确保服务器已安装Docker和Docker Compose。

# 安装Docker curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh # 安装Docker Compose插件 sudo apt-get update && sudo apt-get install docker-compose-plugin

获取配置：下载官方提供的生产环境Docker Compose模板。

mkdir budibase && cd budibase curl -L https://raw.githubusercontent.com/Budibase/budibase/master/hosting/docker-compose.yaml -o docker-compose.yaml

环境变量配置：创建一个.env文件来设置关键配置。以下是最小化配置示例：

# Budibase服务器设置 BUDIBASE_URL=http://你的服务器IP或域名:10000 # 使用外部PostgreSQL（推荐） POSTGRESQL_URL=postgresql://username:password@postgres-host:5432/budibase # 使用外部MinIO/S3 MINIO_URL=http://minio-host:9000 MINIO_ACCESS_KEY=your-access-key MINIO_SECRET_KEY=your-secret-key # JWT密钥，务必修改为强随机字符串 JWT_SECRET=your-very-strong-jwt-secret-key-here

如果你暂时不想配置外部数据库和存储，Budibase会使用容器内自带的，但这不适用于生产环境。

启动服务：
```
docker compose up -d
```
等待几分钟，所有容器启动完毕后，访问http://你的服务器IP:10000即可看到Budibase的登录/注册页面。首次访问需要创建一个管理员账户。

3.3 15分钟构建一个客户反馈管理面板

现在，我们进入Builder，快速创建一个实用应用。假设场景：市场部需要收集和处理来自各个渠道的客户反馈。

创建应用与数据表：
- 登录后，点击“创建新应用”。
- 选择“从空白开始”。
- 在左侧数据侧边栏，点击“+”添加数据源。我们先创建一个“内部表”。
- 将表命名为customer_feedbacks，并添加以下字段：
  - feedback_id(自动编号，主键)
  - customer_name(文本)
  - customer_email(邮箱)
  - feedback_channel(单选：网站表单、邮件、社交媒体、电话)
  - feedback_content(长文本)
  - priority(单选：低、中、高)
  - status(单选：待处理、处理中、已解决、已关闭)
  - assigned_to(关联 -> 关联到Budibase内置的users表)
  - created_at(日期时间，默认值设为“当前时间”)
  - resolved_at(日期时间)
设计主视图 - 反馈列表：
- 点击“创建新界面”，命名为“反馈总览”。
- 从左侧组件库拖入一个“数据提供者”组件，并选择我们刚创建的customer_feedbacks表。
- 在数据提供者内部，拖入一个“表格”组件。Budibase会自动将表格绑定到数据。
- 在表格的设置面板中，你可以选择显示的列、设置列排序、筛选。例如，可以默认按created_at降序排列，并添加一个快速筛选器，只显示status为“待处理”的反馈。
- 为表格启用“行选择”功能，并添加几个顶部按钮：“新建反馈”、“批量分配”、“导出CSV”。
设计详情与编辑视图 - 反馈处理页：
- 在表格组件上，有一个“点击行”的交互设置。将其设置为“导航到界面”，并创建一个新界面，命名为“反馈详情”。
- 在“反馈详情”界面，会自动生成一个上下文，包含当前行的数据（{{ current_row }}）。
- 在这个界面，你可以拖入一个“表单”组件，并将其数据源绑定为{{ current_row }}。表单会自动根据表结构生成字段。
- 你可以调整表单布局，将customer_name、feedback_content等字段设置为只读，而将status、assigned_to、priority等字段保留为可编辑。添加一个“保存更改”按钮。
- 你还可以在旁边添加一个“容器”，用“文本”组件显示一些统计信息，比如{{ current_row.created_at }}的格式化时间。
添加自动化流程 - 自动发送邮件通知：
- 当高优先级的反馈被创建时，我们希望自动发邮件给团队负责人。点击左侧的“自动化”标签页。
- 点击“新建自动化”，触发器选择“行已创建”，数据源选择customer_feedbacks。
- 添加一个“条件”步骤：判断{{ trigger.row.priority }}是否等于“高”。
- 在条件分支内，添加一个“发送邮件”步骤。你需要先在“设置”->“平台设置”中配置SMTP邮件服务器。
- 在邮件步骤中，收件人可以写固定邮箱，或者更高级地从users表中查询。邮件内容可以动态插入反馈信息，如{{ trigger.row.customer_name }} 提交了高优先级反馈：{{ trigger.row.feedback_content }}。
设置权限：
- 点击“发布”旁边的“设置”图标，进入应用设置。
- 在“权限”标签页，你可以为不同角色（管理员、编辑者、查看者）设置精细的权限。例如，市场部同事（编辑者角色）可以创建和编辑所有反馈，而客服同事（查看者角色）只能查看分配给自己的反馈。
- 权限可以控制到“表级别”（能否增删改查某张表）和“行级别”（通过自定义规则，如{{ row.assigned_to }} = {{ user._id }}来控制只能看到自己的任务）。

点击“发布”，你的第一个功能完整的内部应用就上线了。整个过程几乎没有写一行代码，但产出的应用却具备数据管理、工作流、权限控制等企业级功能。

4. 高级功能与深度集成探索

4.1 自动化工作流（Automations）的威力

自动化是Budibase将简单CRUD应用升级为智能业务系统的关键。它不仅仅是一个“如果-那么”的触发器，而是一个完整的可视化流程编排引擎。

丰富的触发器：除了“行创建/更新/删除”，还包括“Webhook调用”、“定时任务”、“应用内按钮点击”等。你可以用定时任务每天凌晨生成报表，或用Webhook接收来自GitHub、Zapier的外部事件。
强大的逻辑步骤：
- 条件与循环：支持if/else分支和遍历数组的循环，可以构建复杂的决策树。
- 数据操作：查询行、创建行、更新行、删除行。你可以在一个自动化中操作多张表，实现事务性逻辑。
- 外部集成：“发送HTTP请求”步骤允许你调用任何外部API。你可以用它将数据同步到第三方系统（如CRM），或从外部API获取数据后写入Budibase表。
- 代码步骤：这是给开发者的“后门”。当内置步骤无法满足需求时，你可以插入一个JavaScript代码块，执行任意自定义逻辑。代码可以访问流程上下文，调用Node.js模块（需在服务器端安装）。
实操案例：用户注册审批流：
1. 触发器：内部表user_registrations有“新行创建”。
2. 步骤1：发送Slack消息到审批频道，包含用户信息和“批准/拒绝”按钮（按钮关联到Slack的交互式消息）。
3. 步骤2：等待，直到接收到来自Slack Webhook的响应（这是一个“等待事件”步骤）。
4. 步骤3：根据Webhook返回的审批结果，更新user_registrations表的状态，并同时决定是否在users表中创建正式用户账号。

4.2 自定义组件的开发与集成

当内置组件库无法满足你的UI需求时，自定义组件是终极解决方案。Budibase自定义组件本质上是一个React组件包。

环境搭建：你需要Node.js环境。使用Budibase CLI工具初始化一个组件项目。
```
npm install -g @budibase/cli budibase components init my-custom-chart cd my-custom-chart
```
这会生成一个标准的项目结构，包含package.json,src目录和配置文件。

开发组件：在src/components目录下创建你的React组件。Budibase提供了专门的Hooks和上下文，让你能轻松获取当前组件绑定的数据、触发操作等。

// 示例：一个简单的KPI卡片组件 import React from “react” import { useBinding } from “@budibase/frontend-core” const MyKPICard = ({ title, value, trend }) => { // 使用useBinding来解析属性中可能存在的绑定表达式，如 `{{ table.column }}` const [resolvedTitle] = useBinding(title) const [resolvedValue] = useBinding(value) return ( <div className=“kpi-card”> <h4>{resolvedTitle}</h4> <div className=“kpi-value”>{resolvedValue}</div> <span>趋势: {trend}</span> </div> ) } export default MyKPICard

你需要在组件的schema.json中定义它的可配置属性（Props），这样在Builder中就可以像设置官方组件一样设置它。

构建与导入：
```
npm run build
```
构建后会生成一个.tar.gz文件。在Budibase Builder的“组件”面板，点击“上传自定义组件”，选择这个文件即可。上传后，你的组件就会出现在组件库中，可以像拖拽按钮、输入框一样使用它。

4.3 用户管理与单点登录（SSO）集成

对于企业级应用，统一身份认证是刚需。Budibase支持多种SSO协议。

OAuth 2.0 / OpenID Connect：这是最通用的方式。你可以在“设置” -> “认证” -> “OAuth 2.0”中配置。需要提供你的身份提供商（如Okta, Auth0, Keycloak, 甚至企业微信、飞书）的客户端ID、密钥、授权和令牌端点等信息。
SAML：对于传统企业，Budibase也支持SAML 2.0协议。
LDAP / Active Directory：可以通过配置OIDC（如果AD FS支持）或使用第三方桥接服务来实现。

配置成功后，用户点击登录按钮时，会被重定向到你的身份提供商进行认证，成功后携带用户信息（如邮箱、姓名、部门）返回Budibase，并自动创建或匹配本地用户账号。你还可以通过映射规则，将IDP返回的用户属性（如组信息）自动转换为Budibase内的角色，实现权限的自动分配。

5. 生产环境部署、运维与性能调优

5.1 高可用架构建议

对于关键业务应用，单点部署的Docker Compose是不够的。以下是面向生产的高可用架构思路：

无状态服务器集群：Budibase Server本身是无状态的（状态存储在数据库和Redis中）。因此，你可以部署多个Server实例，前面用Nginx或HAProxy做负载均衡。这提高了并发处理能力和容错性。
外部化所有状态服务：
- 数据库：使用高可用的PostgreSQL集群（如AWS RDS多AZ部署、或自建的Patroni集群）。
- 对象存储：使用S3或MinIO集群，确保上传的文件高可用。
- 缓存：使用Redis哨兵或集群模式。
- 消息队列：Budibase的自动化工作流依赖一个消息队列（默认使用Redis）。在生产环境中，确保Redis的高可用也保障了工作流的可靠性。
容器编排：使用Kubernetes进行部署是理想选择。Budibase官方提供了Helm Chart，可以方便地定义Deployment、Service、Ingress以及环境变量。利用K8s的Horizontal Pod Autoscaler (HPA)，可以根据CPU/内存使用率自动扩缩容Server实例。

5.2 备份与恢复策略

数据无价，必须建立可靠的备份机制。

应用定义备份：定期通过Budibase的“导出应用”功能，将应用导出为.tar文件。这个文件包含了所有的界面设计、自动化流程和配置。建议将此文件纳入版本控制系统（如Git）。
数据库备份：这是核心。你需要定期备份外部PostgreSQL数据库。可以使用pg_dump命令，或利用云数据库的自动备份功能。
```
# 示例：每日全量备份 pg_dump -h your-postgres-host -U username budibase > /backup/budibase-$(date +%Y%m%d).sql
```
对象存储备份：如果使用S3，可以启用版本控制和跨区域复制。如果使用MinIO，可以使用mc mirror命令定期同步到另一个存储桶或离线介质。
恢复演练：定期在隔离环境中演练恢复流程：1) 部署新的Budibase实例；2) 恢复PostgreSQL数据；3) 恢复对象存储文件；4) 导入应用定义。确保整个流程畅通。

5.3 性能监控与调优

随着应用和用户量的增长，性能监控至关重要。

基础设施监控：使用Prometheus + Grafana监控服务器、PostgreSQL、Redis的CPU、内存、磁盘I/O、网络和关键服务状态。
应用层监控：Budibase Server会输出结构化的JSON日志。你可以使用Fluentd或Filebeat收集这些日志，并发送到ELK（Elasticsearch, Logstash, Kibana）或Loki + Grafana栈中，便于查询错误日志和分析用户行为。
数据库优化：
- 索引：Budibase会自动为内部表的主键和关联字段创建索引。但对于你频繁查询和筛选的外部数据源字段，需要在源数据库手动创建合适的索引。
- 查询优化：避免在Budibase的“查询数据”步骤或绑定表达式中进行全表扫描式的复杂计算。尽量将计算下推到数据库层面，或利用Budibase的“视图”功能对数据进行预处理。
前端优化：
- 分页与虚拟滚动：对于数据量大的表格，务必启用分页或使用“虚拟滚动”组件，避免一次性加载成千上万行数据。
- 减少不必要的绑定：界面上的每个数据绑定（{{ }}）都会在数据变化时触发重新计算和渲染。确保只绑定真正需要动态更新的数据。

6. 常见问题排查与实战心得

6.1 部署与连接类问题

问题1：Docker Compose启动后，访问端口10000报错或无法连接。

排查思路：
1. 检查容器状态：运行docker compose ps，确认所有容器（特别是budibase和proxy）的状态都是“Up”。
2. 查看日志：运行docker compose logs budibase，查看是否有明显的启动错误，如数据库连接失败、环境变量缺失等。
3. 检查端口占用：确保服务器的10000端口没有被其他进程占用。sudo netstat -tulpn | grep :10000。
4. 检查防火墙：如果从外部访问，确保云服务器安全组或本地防火墙放行了10000端口。
实操心得：90%的启动问题源于环境变量配置错误，特别是POSTGRESQL_URL、MINIO_URL和JWT_SECRET。确保.env文件中的连接字符串格式正确，且网络可达。对于MinIO，初次使用还需在MinIO的控制台（默认端口9001）创建Budibase所需的存储桶（bucket）。

问题2：连接外部MySQL数据库失败，提示“Access denied”或“Unknown database”。

排查思路：
1. 确认凭据：在Budibase中输入的数据库地址、端口、用户名、密码必须完全正确。
2. 网络连通性：确保Budibase Server所在的Docker网络或服务器能够访问到目标MySQL实例。如果MySQL在另一台机器，检查防火墙规则。
3. 权限问题：用于连接的MySQL用户必须有从Budibase服务器IP地址连接的权限，并且对目标数据库有SELECT、INSERT等相应操作权限。使用MySQL命令行工具测试连接和权限是最快的方法。
4. 数据库存在性：Budibase连接时需要指定一个已存在的数据库名。请先在MySQL中创建该数据库。

6.2 设计与开发类问题

问题3：自动化流程中的“发送HTTP请求”步骤总是失败。

排查思路：
1. URL和Method：仔细检查请求的URL和HTTP方法（GET/POST/PUT等）是否正确。
2. 请求头与Body：如果需要认证（如API Key），是否在“Headers”中正确添加了？对于POST请求，Body的格式（JSON/Form）和内容是否正确？可以在步骤设置中打开“详细日志”查看实际发出的请求。
3. 超时与重试：网络不稳定的环境可能导致超时。可以适当增加超时时间，并配置重试逻辑（在失败分支后添加“延迟”步骤，然后跳回请求步骤）。
4. HTTPS证书：如果调用自签证书的HTTPS接口，可能会因证书验证失败而报错。在生产环境中应使用有效证书，在测试时可以在服务器层面配置忽略证书验证（不推荐生产环境）。
实操心得：调试自动化流程时，充分利用“测试”功能。你可以在不发布应用的情况下，手动触发自动化并查看每一步的输入输出。对于HTTP请求，可以先用Postman等工具调试通，再把参数复制到Budibase中。

问题4：自定义组件上传后，在Builder中不显示或显示错误。

排查思路：
1. 组件包格式：确保上传的是通过npm run build生成的.tar.gz文件，而不是源代码目录。
2. 版本兼容性：检查自定义组件项目中的@budibase相关依赖版本是否与你的Budibase服务器版本大致兼容。版本差异过大可能导致API不匹配。
3. 控制台错误：打开浏览器的开发者工具（F12），查看Console和Network标签页是否有JavaScript错误或加载失败。这能提供最直接的错误信息。
4. 组件定义：检查components.json和每个组件的schema.json文件，确保组件名称、属性定义等没有语法错误。

6.3 性能与权限类问题

问题5：应用界面加载很慢，特别是表格数据多的时候。

优化方案：
1. 强制分页：在表格组件设置中，将“分页”设置为“服务器端分页”，并设置一个合理的每页行数（如50）。
2. 创建视图：不要直接对庞大的原始表进行复杂筛选和排序。在数据源中创建“视图”，在视图层面通过SQL或查询条件预先过滤和排序数据，界面表格绑定到这个轻量级的视图。
3. 减少初始绑定：检查界面是否在加载时就绑定了大量不需要立即显示的数据。可以考虑使用“容器”的“显示条件”或动态加载技术，让部分数据在用户交互后才加载。
4. 数据库层面优化：如前所述，为外部数据源表的关键查询字段添加索引。

问题6：设置了行级权限，但用户仍然能看到不该看的数据。

排查思路：
1. 权限规则逻辑：行级权限规则是一个返回布尔值的JavaScript表达式。仔细检查你的规则逻辑。例如，规则{{ row.department }} = {{ user.department }}要求row和user对象都有department字段，且值匹配。使用console.log调试规则（输出会在服务器日志中）是很好的方法。
2. 用户上下文：确保{{ user }}对象中包含你规则里用到的属性。这些属性通常来自SSO集成或用户资料表。检查“用户”数据表的结构。
3. 权限继承与覆盖：检查用户所属的角色。权限是叠加的，如果用户有多个角色，其中一个角色有更宽松的权限，可能会覆盖更严格的限制。Budibase的权限系统是“或”逻辑，只要有一个角色允许，操作就被允许。
4. 缓存问题：有时权限更改后，由于浏览器或服务器缓存，不会立即生效。尝试让用户退出重新登录，或清除浏览器缓存。

经过近两年的实践，Budibase已经成为我们团队应对内部工具需求的默认选项。它最大的魅力不在于替代了传统开发，而是极大地压缩了从需求产生到可交付产品之间的“摩擦”。以前需要前后端开发、联调、部署一周的功能，现在产品经理或前端工程师自己花半天就能搭出原型。这让开发者能更专注于核心业务系统的开发，而将那些重复、琐碎但又必要的内部工具需求，高效地分流出去。当然，它并非银弹，复杂的业务逻辑、极致的性能要求、独特的交互设计，仍然需要传统的代码开发。但毫无疑问，Budibase在“快速构建内部应用”这个赛道上，凭借其开源、可自托管、深度可扩展的特性，提供了一个非常漂亮且实用的解决方案。

查看全文

http://www.jsqmd.com/news/706958/