★ FEATURED ARTICLE Thingsboard是目前物联网开源生态里非常活跃的一个平台项目我把它的源代码在macOS上完整编译、启动过不止一次过程中踩了不少坑也摸清了整个构建链条的脾气。如果你正准备在自己的Mac上拉取Thingsboard源码想编译出一个可以调试、可以二次开发的本地环境这篇文章应该能帮你省下大量试错的时间。我先说说这套平台能干什么。Thingsboard把设备接入、数据遥测、规则引擎、可视化仪表盘和REST API都打包在一个工程里是国内物联网仿真实训、设备管理和教学演示中最常被拿来搭环境的一类开源平台。官方给了Docker镜像想快速跑demo的话的确方便但我们做源码编译的人目标往往不是“跑起来看一眼”而是要在本地把断点打进去、把设备动态创建流程调通、甚至把所有实验项目逐个搭出来这就必须走“源代码编译与启动”这条路。这篇文章以Thingsboard 3.5.0版本为准记录了我在macOS上从零开始编译和启动的全过程包括环境准备、源码结构理解、构建命令选择、PostgreSQL数据库初始化、首次启动验证以及一堆macOS平台特有的坑。适合两类人一类是做物联网平台二次开发的工程师需要在源码层面调试规则引擎或设备接入另一类是学校或培训机构里做物联网仿真实训的老师和学生需要在一台Mac上把演示环境彻底跑通而不是只停留在界面截图层面。1. 编译前的准备先想清楚为什么要源码编译1.1 避开Docker镜像的理由很多人的第一反应是项目主页写得清清楚楚直接执行docker run就能拉起来一个完整环境为什么还要自己编译诚然Docker是验证一个开源项目最快的方式也是官方推荐的体验路径。但有一个现实问题Docker镜像里装的是编译好的jar包、打包完的静态资源你自己在GitHub上改了什么代码镜像里完全感知不到。你在宿主机上挂载几个配置文件还能勉强做做目录映射想改一行规则引擎的Java代码那就只能重新构建镜像。我在调研阶段需要确认规则链节点到底是怎么执行的、设备遥测经过哪些管道才落库、RPC下发走的是哪条传输链路。这些东西光靠读文档和翻镜像文件看不全必须把源码握在手里用IDE一行行看、一个断点一个断点打。所以对我来说源码编译不是绕路反而是最直接的路。另外还有一层考虑Docker镜像的版本更新节奏和源码tag并不是时刻对齐的。有时候你用官方镜像跑起来后想看版本号对应的源码却发现镜像里的代码结构和当前tag对不上。自己编译版本锁定非常明确git checkout到哪个tag编译出来的东西就是这个版本的后面做二次开发和升级都更容易把控。1.2 macOS环境的基础工具清单在开始编译之前得先把本地的工具链理清楚。我在Apple SiliconM1 Pro和Intel老款MacBook上各编译过一次两个平台的核心流程完全一致差别主要在编译耗时和个别原生依赖的处理上。整体需要准备以下东西JDK 11。Thingsboard 3.5系列要求Java 11作为编译和运行基线JDK 8会直接编不过JDK 17在部分模块的代码生成阶段也会出问题。推荐用brew install openjdk11装一个独立版本不要动系统自带的JDK。Maven 3.6.3以上。Homebrew装出来的Maven默认版本一般够用关键是把JAVA_HOME指对。Node.js 16或18 LTS。前端工程ui-ngx是Angular项目构建脚本和依赖树对Node版本有一定要求太新的Node 20在某些npm包上会出现兼容性报错。PostgreSQL 12以上版本编译本身不需要数据库但首次启动做schema初始化时对版本有硬性要求。我用PostgreSQL 14和16都验证过。Git、IntelliJ IDEACommunity版即可、一个趁手的终端工具。提示如果你机器上同时装了sdkman、Homebrew、多版本JDK务必在编译前确认echo $JAVA_HOME的输出是不是你期望的那个JDK 11路径。我第一次编译就栽在这里全局环境指向JDK 17结果Maven编译时一部分模块用11的语法、一部分模块被17编译报错信息五花八门排查了很久才发现是环境变量的问题。1.3 磁盘空间、内存与编译时间预期Thingsboard不是一个轻量级项目全量编译极其“吃”资源。先说磁盘Maven本地仓库会新增大约1.2GB到1.5GB的依赖包前端ui-ngx的node_modules装完接近800MB各个模块的target目录加起来也要1GB左右。我建议编译前先给磁盘留出6GB以上的空余空间否则编到一半磁盘满掉Maven会抛非常不好定位的IO错误。内存方面后端application模块的JVM启动参数默认在1GB到1.5GB之间前端构建阶段Angular的AOT编译会把内存占用推上去16GB内存的机器在UI打包时会明显听到风扇狂转8GB内存会比较吃力但也不是完全走不通可以在npm脚本里加--max_old_space_size4096来缓解。编译时间我实测过M1 Pro全量构建在28到35分钟之间Intel 2020款MacBook Pro全量构建超过60分钟。主要瓶颈在ui-ngx模块的npm install和angular build上。如果你的目标只是跑后端做接口调试完全可以跳过前端构建时间能压缩到10分钟以内。2. 源码结构拆解构建关系比想象中更纠缠2.1 顶层目录怎么看拉取源码后顶层目录会对新手造成不小的冲击因为模块实在太多了。我按自己的理解把它分成几个组application后端主模块所有服务的启动入口都在这也是我们最终要运行的东西。common公共库包括common/data、common/message、common/transport等子模块设备元数据、消息结构体、传输层共享代码基本都在这层。dao数据访问层负责PostgreSQL和Cassandra的适配、实体映射、查询逻辑。transport协议接入层MQTT、HTTP、CoAP、LwM2M等设备接入协议都在这个目录下分模块管理。rule-engine规则引擎核心包含规则链的容器、节点组件和调试相关能力。ui-ngx前端项目Angular技术栈负责控制台、仪表盘、设备管理界面。msa/msgea微服务相关模块单机部署时不需要关注。tools数据库迁移、工具脚本、远程调试辅助脚本。刚开始接触这个项目时千万不要试图把每个模块都读完会直接劝退。我的建议是带着问题去看设备接入失败就去transport下对应协议模块规则链不生效就去rule-engine/components里找节点描述器界面上的数据不对先通过浏览器的Network面板定位请求路径再回到后端Controller层找接口。2.2 Java后端与Angular前端的构建耦合关系Thingsboard的构建流程有一个特殊设计后端Maven构建会“顺带”把前端也构建了两者是绑定的。根目录的pom.xml定义了这样的逻辑——当Maven执行到某个阶段时会通过exec-maven-plugin或frontend-maven-plugin去调用npm脚本把Angular编译出来的静态资源放进后端jar包的静态目录里。这个设计对最终部署是友好的一个jar包搞定全栈。但对日常开发来说就很别扭因为你在前端改一行代码不可能为了看效果就重新打整个后端jar。我实际调试中采用的是“前后端分离调试”的方式后端在IDEA里正常启动监听8080端口前端在ui-ngx目录下单独执行npm start启动Angular dev server监听4200端口然后通过proxy配置把/api请求转发到8080。这样改前端秒级生效改后端打断点也互不干扰。如果你想省掉前端的构建Maven命令里加-DskipUI即可。这个参数会让pom跳过ui-ngx模块的构建直接编译Java部分。反之如果你只想单独构建前端就进ui-ngx目录执行npm install npm run build或者直接npm start做热调试。2.3 编译指令的选择逻辑根目录执行Maven命令时有几个参数经常被混用我把它们的含义整理一下-DskipTests跳过单元测试。编译阶段强烈建议加上因为部分集成测试会尝试启动内嵌数据库或连接外部的中间件没有准备环境的话很容易挂。-DskipUI跳过前端构建。后端开发主力参数。-Dlicense.skiptrue跳过license检查插件这个参数在公司代理网络环境下很有用因为license插件有时会去下载外部文件导致卡住。-Dmaven.javadoc.skiptrue跳过javadoc生成能加速且避免文档生成报错。全量构建命令是mvn clean install -DskipTests后端构建命令是mvn clean install -DskipTests -DskipUI我实际工作中第一次编译会走全量构建把前端资源也打出来验证整套工程完整可跑。之后日常开发都走后端构建前端单独用dev server调试。这两条命令的差异决定了你最后能否用一个jar包启动出完整界面还是只能访问REST API别搞混。3. 完整编译流程与关键参数调整3.1 拉取源码、分支切换与Maven配置源码拉取很简单但细节里有坑。官方仓库地址是https://github.com/thingsboard/thingsboard.git我编译时用的命令如下git clone https://github.com/thingsboard/thingsboard.git cd thingsboard git checkout v3.5.0这里要注意Thingsboard没有依赖git submodule但transport-lwm2m模块会从外部仓库拉一些编解码相关的依赖网络条件不好的时候偶发空目录问题。如果发现某些模块目录是空的先执行git pull --recurse-submodules再确认一下目录大小一个正常的源码仓库存放好之后大约在250MB到400MB之间。如果明显偏小多半是拉取不完整建议重新clone。Maven配置方面国内网络环境下强烈建议把中央仓库镜像切到阿里云或华为云因为Thingsboard的依赖数量很大直接访问中央仓库会经常遇到超时。修改~/.m2/settings.xml加入mirror即可。另外要设置Maven运行时的JVM内存防止大型模块编译时OutOfMemoryErrorexport MAVEN_OPTS-Xmx1536m -XX:MaxMetaspaceSize512m如果你的构建机器内存只有8GB可以再把Xmx调到1024m。不要低于这个值Thingsboard根pom里有些模块的依赖解析和代码生成工具会比较吃内存。3.2 前端构建的隐藏关卡全量构建时真正花时间最多的地方在ui-ngx模块。Maven执行到这个模块时会自动触发npm install然后执行Angular的生产构建。这个阶段有几个典型问题需要提前处理第一npm registry源。如果不切换镜像源npm install极易超时。建议先设置npm config set registry https://registry.npmmirror.com第二node_modules的完整安装。Thingsboard前端的依赖树非常庞大安装过程会看到大量warning日志这些基本不用管。但如果出现gyp相关的错误或者提示找不到node-sass、sass那就是Node版本和项目依赖库不兼容先检查node -v是否在16或18。我遇到过在Node 20上编译时报Error: error:0308010C:digital envelope routines::unsupported这是OpenSSL版本策略变化导致的降低Node版本到18即可解决。第三前端构建的内存限制。Angular的生产构建在低内存机器上容易因为JavaScript堆内存不足崩溃日志里会出现FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory。这种情况可以在ui-ngx目录下的package.json里调整脚本给node进程加--max_old_space_size4096或者在执行构建时临时设置export NODE_OPTIONS--max-old-space-size4096我实测过M1 Pro上这步能平稳跑完Intel老机器上加了参数也会明显变慢但至少不会再崩。3.3 编译产物与关键目录说明编译完成后有几个关键产物和目录值得记住后面调试会频繁用到application/target/thingsboard-3.5.0-boot.jar最终可执行的后端jar包Spring Boot打包方式内含前端静态资源。ui-ngx/target/classes/static前端编译产物目录如果这个目录不存在或为空说明你用了-DskipUI。transport/mqtt/target、transport/http/target等传输模块的jar包单机模式下并不是独立进程而是被打进application依赖里。如果你用了-DskipUI编译想后来补前端资源怎么办两个选择一个是重新全量编译一次另一个是单独在ui-ngx目录构建前端然后把dist目录内容拷贝到后端静态资源目录。后者操作起来比较绕我更推荐在计划全量部署时一次编完。注意编译完成后如果体积明显小于预期比如只有几十MB大概率是某个大模块被跳过了。检查日志里是否有Skipping ui-ngx之类的输出以及application目录下的jar包是否完整。4. 数据库准备与配置文件详解4.1 PostgreSQL初始化与库表准备Thingsboard默认使用PostgreSQL作为元数据库启动时会自动执行建表脚本、初始化默认配置。因此在启动之前必须先把PostgreSQL跑起来并创建好库和用户。macOS上用Homebrew安装PostgreSQL是最省事的brew install postgresql14 brew services start postgresql14然后创建数据库和专用用户。我习惯为Thingsboard单独建一个用户而不是直接用超级用户避免权限过大带来其他风险createdb thingsboard createuser thingsboard -P按提示输入两次密码比如thingsboard。然后给这个用户授权psql thingsboard -c GRANT ALL PRIVILEGES ON DATABASE thingsboard TO thingsboard;这里有一个细节Thingsboard首次启动时会在thingsboard库中创建大量数据表包括字典表、规则链表、设备信息表等。它要求数据库用户具备DDL权限如果你用了一个只有DML权限的只读用户启动就会在schema更新阶段直接失败。所以建完库之后务必确认thingsboard用户能正常连库并执行建表语句。4.2 thingsboard.yml的核心配置项Thingsboard的配置文件名固定叫thingsboard.yml在application模块的src/main/resources目录下。如果你用IDEA启动改的是源码里的这份如果用java -jar启动jar包则需要通过命令行参数或者外部配置文件覆盖。三个核心配置段先说清楚spring: datasource: url: jdbc:postgresql://localhost:5432/thingsboard username: thingsboard password: thingsboard server: port: 8080如果你的PostgreSQL跑在非默认端口把url里的5432改掉即可。另外还有两个容易被忽视但实际影响巨大的配置项install.load_demo: true这个开关注入demo数据。第一次启动打开后系统会自动创建demo设备、客户、仪表盘和规则链对于做物联网仿真实训、教学演示特别有用。但注意它只会在数据库初始化阶段生效如果库已经有数据了这个开关不会重复注入。logging.level.org.thingsboard.server: INFO日志级别。排查问题时可以临时改成DEBUG信息量会非常大尤其是规则引擎的节点执行链路会完整打印出来。我个人建议第一次启动时打开install.load_demo这样登录后能看到现成的仪表盘和数据对快速理解平台功能很有帮助。4.3 首次启动时应该关注哪些日志启动后端时我习惯在命令行窗口直接前台运行观察日志输出java -jar application/target/thingsboard-3.5.0-boot.jar或者如果是IDEA里运行ThingsboardServerApplication这个类日志会直接输出在Console面板。首次启动的关键日志序列如下Starting Thingsboard Installation表示进入了初始化流程。Updating database schema开始建表或更新表结构。Installation finished successfully初始化完成。Started ThingsboardServerApplication in xxx secondsSpring Boot启动完成。Tomcat started on port(s): 8080HTTP服务可用。看到Started ThingsboardServerApplication时很多新手以为万事大吉了其实还有一步要确认平台内部的规则引擎、传输服务是否也成功初始化了。查看日志有没有以下一行Thingsboard Transport MQTT started如果只看到Tomcat启动但MQTT transport初始化失败设备仍然连不上。这种情况通常在日志更早的地方会看到端口占用或协议初始化异常。5. 启动后端服务与多模块调试技巧5.1 三种启动方式对比macOS上启动Thingsboard后端我试过三种方式各有适用场景。方式一命令行java -jar application/target/thingsboard-3.5.0-boot.jar。这种方式最接近正式部署读取的配置jar包内部的yml适合验证最终产物能否独立运行。方式二IDEA中RunThingsboardServerApplication。这是日常后端开发最常用的方式优点是可以打断点、看变量、热更新部分代码。注意IDEA读取的是源码resouces下的yml不是jar包里的所以两者配置可能不一致。如果你改了源码里的yml记得Rebuild让IDEA加载新配置。方式三后端在IDEA跑、前端用npm start单独跑4200端口通过proxy把API请求转给8080。这是前端联调的最佳方案也是我日常开发的主力模式。对于刚接触这个项目的读者我建议先用方式二。因为你在阅读代码的过程中随时可能想在某一行打个断点IDEA的体验远胜命令行。5.2 单机模式下传输层模块如何协同Thingsboard单机部署时应用进程内部已经集成了所有能力——HTTP、MQTT、规则引擎、设备管理、Web UI都在同一个Java进程里。不需要像微服务部署那样单独起transport进程。但这里有容易踩的坑如果你修改了transport/mqtt模块下的Handler代码直接重启IDEA里的Application是不生效的。因为传输模块在编译阶段被打成了jar包作为依赖被主程序引用而IDEA运行时用的是模块依赖。你需要先执行mvn install -pl transport/mqtt -am -DskipTests -DskipUI把改动后的transport模块安装到本地仓库然后再启动主程序。否则你以为改了代码实际跑的依然是旧依赖。5.3 用登录API快速确认服务状态强烈建议用curl登录一下API来确认服务真的健康而不是只看页面能不能打开。默认的租户账号是tenantthingsboard.org密码是tenant。登录接口如下curl -X POST http://localhost:8080/api/auth/login \ -H Content-Type: application/json \ -d {username:tenantthingsboard.org,password:tenant}如果返回结果是一个带token字段的JSON说明后端服务和数据库都正常。这个方式比打开浏览器还快而且能定位问题出在前端还是后端。如果你打开页面是空白的但curl接口正常问题基本在前端构建产物如果curl都失败那就得往后端日志和数据库排。我平时写脚本做自动化检查时会把这个登录请求循环执行直到返回成功为止比盯日志更可靠。6. 常见问题与macOS平台专属排查6.1 编译失败UnsupportedClassVersionError这个报错在Maven编译阶段非常常见具体信息大致是class file has wrong version 61.0, should be 55.0。61.0对应Java 1755.0对应Java 11也就是说你的构建工具用了新JDK去编译但项目要求是JDK 11。解决办法就是切换JDKexport JAVA_HOME/usr/libexec/java_home -v 11然后重新编译。如果你用的是sdkmansdk use java 11.0.20-tem这里要注意只改终端的环境变量是不够的IDEA里的Project SDK也得设置成11。Mac上IDEA默认可能使用捆绑的JBR必须手动在Project Structure里添加一个JDK 11的路径。6.2 数据库连接失败HikariPool-1 Exception启动时日志出现HikariPool-1 - Exception during pool initialization绝大多数是这四种原因PostgreSQL没启动、库名不对、用户名密码不对、端口不对。排查顺序我很固定先确认PostgreSQL进程在跑ps aux | grep postgres尝试用配置里的用户手工连库psql -d thingsboard -U thingsboard能连上说明数据库没问题。核对yml里的url、username、password是否与实测一致。如果你用的是IDEA启动确认IDEA加载的配置文件是你改的那份不要被target路径下的旧配置干扰。还有一个小细节macOS自带的pgAdmin或Homebrew版PostgreSQL默认端口都是5432但如果你的机器上还跑着其他数据库服务占用了端口连接字符串里的端口号就得改。6.3 前端构建报错cannot find module angular/coreui-ngx模块执行构建时找不到本地Angular依赖原因几乎都是node_modules没有完整安装。遇到这个报错先别急着改代码把依赖重装一遍cd ui-ngx rm -rf node_modules npm cache verify npm install如果重装后依然报错检查npm版本过老或过新的npm对lock文件的处理都可能有兼容问题。我用的是npm 8稳定版。另外注意npm install阶段如果使用了公司内部的npm代理某些包可能被代理缓存成损坏的文件这时候npm cache verify甚至npm cache clean --force才能真正解决。6.4 macOS特有坑SDKMAN切换JDK后IDE不生效SDKMAN在终端里切换JDK很好用但IDEA不认SDKMAN的环境变量。具体表现是终端编译一切正常IDEA里启动却报“无效的源发行版11”或“Error: java: release version 11 not supported”。原因是IDEA的Project Structure维护着自己的一套JDK列表。解决办法很简单到Preferences → Build, Execution, Deployment → Compiler → Java Compiler确认字节码版本是11再到Project Structure → Project → SDK选择JDK 11路径。如果你安装的是Homebrew版openjdk11路径一般在/usr/local/Cellar/openjdk11/11.x.x/libexec/openjdk.jdk/Contents/HomeApple Silicon下则位于/opt/homebrew/Cellar。这个坑每次重装系统或切换代码版本时都会出现时间长了我也习惯了先把三处对齐——终端JAVA_HOME、IDEA Project SDK、Maven runner里的JRE设置。6.5 启动慢或内存不足自动退出或卡在初始化Thingsboard初始化时涉及大量表的创建和默认数据插入如果机器内存紧张会看到进程被系统杀掉或长时间无响应。这时先看系统日志确认是否是内存问题然后用JVM参数压缩内存占用。通过命令行启动时可以用java -Xmx512m -jar application/target/thingsboard-3.5.0-boot.jar但注意Thingsboard规则引擎的初始化相对耗时内存太小可能导致某些节点组件加载失败。我的经验是8GB物理内存的Mac上给JVM 768m能勉强跑通但体验不好。如果条件允许还是建议把开发机升到16GB以上。6.6 schema更新报错数据库版本不兼容Thingsboard每次版本升级都会比对库表结构和代码期望的结构并自动执行增量升级脚本。如果你用的是老版本的PostgreSQL比如9.x或10某些字段类型、索引语法、存储过程可能不支持导致schema升级脚本执行失败日志里会直接抛出SQLException并指出某个语句。现在的Thingsboard最低要求是PostgreSQL 12。我在macOS上就直接用Homebrew的postgresql14全程没有遇到schema问题。如果不想重装也可以用Docker起一个PostgreSQL 14的容器端口映射到5432本质上一样。如果你之前跑过别的版本的Thingsboard、数据库里残留旧数据也会出现schema版本对不上。最省事的办法是建一个全新的空白库重新初始化。数据不重要的情况下千万不要花时间试着“修复”旧库我试过一次最后还是重新建库最干净。6.7 页面空白但不报错后端启动正常、接口正常但打开8080端口看到的却是空白页或404问题几乎一定出在前端资源缺失上。快速验证方法是查看页面Network请求如果静态资源请求返回404说明jar包里的static目录是空的。这种情况通常是因为你用了-DskipUI编译。解决办法有二一是重新全量编译一次二是临时用前端dev server顶上。我在快速验证后端逻辑时第二种办法明显更高效。毕竟全量编译一次要半小时而npm start只需要两分钟。7. 从启动走向实战动态创建设备与实训扩展7.1 基于REST API动态创建设备编译启动的终极目标是为了在真实业务里灵活使用这个平台。很多人关心的热点问题之一是如何基于Thingsboard动态创建指定设备而不是在UI界面里手工点击添加。动态创建设备的标准路径是先调用登录接口拿到JWT token然后用这个token请求设备创建接口。核心调用步骤如下TOKEN$(curl -X POST http://localhost:8080/api/auth/login \ -H Content-Type: application/json \ -d {username:tenantthingsboard.org,password:tenant} | jq -r .token) curl -X POST http://localhost:8080/api/device \ -H Content-Type: application/json \ -H X-Authorization: Bearer $TOKEN \ -d { name: demo-device-001, type: default, additionalInfo: {description: dynamic created device} }创建成功后响应会携带设备的id和accessToken。accessToken是设备端连接平台的凭据MQTT接入时用户名就是它。动态创建指定设备的优势在于可以在自动化脚本里批量导入设备比如从一个Excel表格读取设备编号循环调用创建接口一次性建出几百台虚拟设备。这在物联网仿真实训里非常实用不用手工在界面里一台台点。7.2 物联网仿真实训平台常见实验项目在高校和培训机构里Thingsboard仿真实训最常出现的几个实验项目包括温湿度数据采集与展示、设备告警规则配置、遥测数据历史曲线绘制、设备RPC远程控制、网关批量接入模拟、多用户权限隔离演示。这些实验项目全部可以基于编译启动的本地平台完成。以告警规则为例在规则引擎中配置一个规则链监听post-telemetry消息当温度超过阈值时触发告警同时联动仪表盘显示告警状态。整个过程不需要额外安装任何中间件PostgreSQL加上Thingsboard单机进程就足够。7.3 温湿度上报演示链路搭建展开讲一个最常用的温湿度上报链路。设备端用一个MQTT客户端连接tcp://localhost:1883accessToken作为username发布消息到v1/devices/me/telemetry。上报数据格式如下{ temperature: 26.5, humidity: 58 }平台收到遥测后在数据库里会生成对应的时间序列数据。之后在仪表盘上添加一个设备遥测图表组件选择温度变量就能看到实时曲线。如果温度超过配置的阈值规则引擎会触发告警后端日志里能看到告警相关的记录。实际做这类实验时要注意MQTT broker默认端口是1883Thingsboard单机模式下MQTT transport默认开启。如果连接失败先检查日志里是否有Thingsboard Transport MQTT started再检查防火墙和端口占用。macOS上偶尔会有其他服务占用1883端口的情况可以修改yml里transport.mqtt.bind_port来换端口。8. 写在最后一套跑通之后的价值从环境准备到全量编译、从数据库初始化到首次启动这条路我走过很多次了。说句实在话Thingsboard源码编译启动本身并不复杂真正花时间的部分其实是环境的版本匹配——JDK、Maven、Node、PostgreSQL、npm镜像每个环节差一个版本报错就很难看。我个人的经验是第一次编译时不要追求一次成功先分阶段验证。先把后端用-DskipUI编译出来启动起来确认数据库和API正常再单独构建前端用dev server联调都通了之后再做一次全量构建验证最终jar包能独立跑。这样即使某一环节出错排查范围会小很多。最后再分享一个小技巧如果你打算长期在这个平台上做二次开发给每个版本保持一份单独的数据库副本。比如跑3.5.0就用thingsboard_350库想升到3.6再建一个thingsboard_360库切换版本时改一下yml就行不用反复重建数据库。这个习惯帮我省下了无数时间也避免了好几次因为版本升级把旧库搞乱导致的灾难。编译编译源码、启动一个物联网平台这种事情本身不难难在把每个环节的“为什么”都想明白。等你在macOS上顺利看到Tomcat started on port(s): 8080那一刻整个平台的架构脉络也差不多印在脑子里了。后面无论是做动态创建设备、搭实训项目还是深度定制功能都会从这段经历里持续受益。
阅读完成 · 觉得有帮助？
