企业官网建设流程全解析

过去几年我接触了不少做 IoT 平台和系统集成的公司，大家几乎都会遇到同一个瓶颈：底层设备接入做得差不多了，可客户的定制需求一来，就发现平台把手脚捆死了。要么是接口文档聊胜于无，要么是数据库表结构一团乱麻，想在别人的地基上盖自己的楼，结果连承重墙在哪都不知道。今天我想借着拉孚的 DeepBasic Folar 这个物联基座，聊聊软件公司如何真正把二次开发这件事落地，从开放接口到示例代码再到数据库结构，一次性讲透。

这玩意儿到底是干什么的，我先用一句话说清楚：它是一套已经帮你搞定设备接入、数据采集、规则引擎、告警通知这些底层脏活累活的物联网基础平台，你的团队只需要专注在业务逻辑和客户现场的定制功能上。如果你所在的公司正打算从零开始做物联网项目，或者已经在用类似平台但被定制化需求折磨得够呛，这篇内容应该能帮你省下不少试错的成本。

1. 物联基座的整体设计与二次开发思路拆解

1.1 物联基座到底是什么，为什么软件公司需要它

我先说个现实情况。很多软件公司接物联网项目，第一反应是"自己搞一套平台"。结果呢，设备接入协议一堆，MQTT、Modbus、OPC UA、HTTP 轮询，每个都要从零写；数据要存，时序库、关系库、缓存怎么搭配要琢磨；告警要推，短信、邮件、微信模板要对接。等到这些基础设施做完，半年过去了，客户要的业务功能还没开始动。这就是典型的重复造轮子。

物联基座的核心价值就在于把这些"轮子"提前做好并且做扎实。DeepBasic Folar 的逻辑是，把设备管理、数据采集、规则联动、告警中心这些通用能力沉淀成平台功能，对外提供清晰的开放接口和可查的数据库结构，让软件公司不再需要关心设备怎么连、数据怎么存，而是把精力放在客户真正愿意付钱的那部分——业务可视化、流程定制、系统集成。

从我实际体验来看，这个定位想得很清楚。它不是替代你做业务系统，而是给你一个稳的地基。你的二次开发工作，本质上是在这个地基上做三件事：扩展设备接入能力、定制业务处理逻辑、对接客户已有的业务系统。只要这三条路是通的，平台就是称手的工具；如果这三条路哪条被堵死了，再花哨的功能都是空中楼阁。

1.2 二次开发的三种典型模式与选型逻辑

我在多个物联网项目里摸爬滚打后，总结出软件公司基于物联基座做二次开发，基本逃不出以下三种模式。

第一种是接口扩展型。基座已经把设备接入、数据存储、告警推送做好了，你需要通过开放接口获取设备数据、下发控制指令、查询告警记录。这种模式适合做上层应用开发的团队，你不需要碰底层，只需要把平台当成一个数据中台来用。比如做一个能耗管理大屏，数据来源就是基座的开放接口。

第二种是插件定制型。基座提供了某种插件机制或者事件回调机制，你可以在特定节点插入自己的代码逻辑。比如设备上报数据后，你希望做一次自定义的数据清洗或者业务判断，然后再决定是否入库或者触发告警。这种模式适合有一定平台定制需求的场景。

第三种是深度嵌模型。你直接基于基座的数据库结构做扩展，增加自己的业务表，与基座的原生表建立关联，甚至修改部分平台行为逻辑。这种模式适合那些需要对平台进行深度改造的团队，但风险也最高，一旦升级平台版本，你的改动可能面临冲突。

我见过不少团队一上来就想做第三种，觉得不改数据库就不叫二次开发。实际上，正确的思路是优先用第一种，必须动态处理才考虑第二种，最后实在绕不过去才动数据库。这个选择顺序能帮你少踩很多坑。

2. 开放接口全解析：认证、调用与数据模型

2.1 接口认证方式与安全机制

DeepBasic Folar 的开放接口在设计上走得是行业比较主流的路线——基于 Token 的认证机制。你需要在平台后台创建应用凭证，拿到 AppKey 和 AppSecret，然后通过接口换取访问令牌。这里有几个细节值得注意。

首先，Token 是有有效期的，一般是 2 小时左右（不同版本可能有差异），过期后需要用 Refresh Token 去刷新。很多团队第一次对接时，把 Token 当成永久凭证来用，结果上线跑了两小时，所有接口突然全部 401，排查了半天才发现是 Token 过期了。所以代码里必须实现 Token 的自动续期逻辑。

其次，所有接口请求都需要校验签名。Folar 的签名规则比较简单：将请求参数按照键名 ASCII 码升序排列，拼接成字符串，加上 AppSecret 做 HMAC-SHA256 运算，得到的摘要放在请求头里。这个机制主要是防止请求被篡改。我在对接时习惯把签名逻辑封装成一个公共方法，因为每个接口都要用到，写一遍太蠢了。

最后，权限维度要搞清楚。Folar 的接口权限是分级的：应用级权限、项目级权限和设备级权限。你在后台创建应用时就要声明这个应用能访问哪些项目、哪些设备。这样做的好处是，当你有多个客户时，可以给每个客户单独创建应用，互相之间数据隔离，不会串。

2.2 核心接口资源与数据模型

Folar 开放接口的资源设计比较贴近物联网业务的实际场景，我梳理一下最常用的几组。

设备管理类接口：包括设备列表查询、设备详情、设备状态查询、设备创建和删除。这里要注意，Folar 里的设备是挂在产品（Product）下的，产品定义了设备的属性、事件和服务。所以你查设备列表时，通常需要先拿到产品的标识，再按产品维度去过滤设备。

数据查询类接口：包括属性最新值查询、属性历史数据查询、事件记录查询。这类接口是上层应用开发最常用的，做报表也好、做大屏也好，都靠它们。历史数据查询一般都支持时间范围、分页和聚合参数。举个例子，你要查某台设备最近一周的温度平均值，可以在请求参数里指定聚合方式为 AVG，时间间隔为 1 小时，平台会返回按小时聚合好的数据，大大减少了前端的计算量。

指令下发类接口：包括设备属性设置、服务调用。这类接口是双向通信的关键。比如你做了一个手机 App 远程控制灯光，本质就是调用这个接口，把目标设备的某个属性值设置为"开"。下发接口一般是异步的，调用后立即返回一个任务 ID，需要通过查询任务状态来确认设备是否真正执行成功。

告警与事件接口：包括告警记录查询、告警处理、事件订阅配置。Folar 支持 Webhook 方式的事件订阅，你可以配置一个回调地址，当设备离线、告警触发、数据异常时，平台主动推送到你的服务器。这个能力在做运维大屏或者工单系统时非常有用，省去了轮询的麻烦。

2.3 分页、过滤与关联查询的实战细节

接口用多了你会发现，PaaS 平台的接口文档不会告诉你一些隐性的使用技巧，但偏偏这些技巧决定了你的开发效率。比如分页，Folar 的列表接口默认一页 10 条，最大支持 100 条。很多人第一版代码直接把每页大小拉满，但实际业务中这样做并不好。因为一次拉太多数据，接口响应时间会明显变长，而且数据量大了之后，即使只取前 100 条，系统也要扫描大量记录。我建议的做法是：实时性要求高的场景用 20 条左右的分页，批量导出场景用游标加循环拉取的方式。

再比如过滤。设备列表接口支持按设备名称模糊查询、按设备状态过滤、按标签查询。这些过滤条件看起来简单，但组合起来就能解决很多实际问题。我曾经接一个客户需求，要在第三方系统里展示"某栋楼所有在线且类型为温湿度传感器的设备"，就是一个请求带三个过滤参数的事。

关联查询是一个容易踩坑的点。Folar 的设备接口返回的数据里，包含 ProductId、ProjectId 等关联字段，但不会自动展开成名称。你拿到的是一个 ID，要显示名称还得再查产品详情或项目详情。我建议在代码里做一个简单的缓存层，把产品名称和项目名称缓存起来，避免每个设备都去查一次关联数据，性能差距非常明显。

3. 示例代码实操：从环境搭建到典型场景实现

3.1 开发环境准备与必要配置

说一万遍接口文档，不如跑通一段真实代码。我以 Java 语言为例，演示一下基于 Folar 开放接口做二次开发时的标准姿势。为什么选 Java？因为在我接触的软件公司里，Java 后端的占比还是最高的，而且物联网项目大多和 Spring Boot 配套使用，生态比较成熟。

环境准备阶段，你需要做三件事。第一，拿到 Folar 平台的环境信息，包括接口地址、AppKey、AppSecret。第二，在项目中引入 HTTP 客户端依赖，我用的是 OkHttp，你也可以用 Hutool 的 HttpUtil，都是一样的。第三，建一个常量类，把接口地址和凭证信息统一管理，方便后续维护。

public class FolarConfig { // 平台接口地址，根据实际环境修改 public static final String BASE_URL = "https://your-folar-server/api"; // 应用凭证 public static final String APP_KEY = "your-app-key"; public static final String APP_SECRET = "your-app-secret"; // 接口路径 public static final String API_LOGIN = "/auth/token"; public static final String API_DEVICE_LIST = "/devices"; }

这里有个细节很重要：凭证信息千万不要硬编码在代码里提交到 Git 仓库，尤其是和客户对接时，凭证泄露会带来安全风险。正确的做法是放到配置中心或者环境变量里，部署时再注入。

3.2 Token 获取与自动续期的标准代码模板

Token 获取是调用所有接口的第一步。Folar 的认证接口是标准的 OAuth2 密码模式，你需要用 AppKey 和 AppSecret 换 Token。有一个容易忽略的点：OAuth2 的 Token 端点通常会校验grant_type参数，值是client_credentials，写错了会直接报错。

下面这段代码是我在实际项目中封装好的 Token 管理类，核心思路是用静态变量保存 Token，配合一个定时任务在过期前自动刷新。

@Component public class TokenManager { private static final String GRANT_TYPE = "client_credentials"; private String accessToken; private long expireTime; @PostConstruct public void init() { refreshToken(); // 定时刷新，每30分钟执行一次 Executors.newScheduledThreadPool(1).scheduleAtFixedRate(this::refreshToken, 30, 30, TimeUnit.MINUTES); } public synchronized String getToken() { if (System.currentTimeMillis() > expireTime - 60 * 1000) { refreshToken(); } return accessToken; } private void refreshToken() { // 构建请求参数 Map<String, String> params = new HashMap<>(); params.put("grant_type", GRANT_TYPE); params.put("app_key", FolarConfig.APP_KEY); params.put("app_secret", FolarConfig.APP_SECRET); // 发送请求并解析响应 String json = sendPost(FolarConfig.BASE_URL + FolarConfig.API_LOGIN, params); JSONObject obj = JSON.parseObject(json); this.accessToken = obj.getString("access_token"); this.expireTime = System.currentTimeMillis() + obj.getLong("expires_in") * 1000; } }

定时任务的周期可以自己做取舍。我设的是每 30 分钟刷一次，实际 Token 有效期是 2 小时，这个间隔足够安全，也不会有频繁刷新带来的不必要请求。需要注意的是，expireTime - 60 * 1000这段逻辑是提前一分钟判断过期，避免在临界点请求时拿到失效 Token。

3.3 设备数据查询与指令下发的完整链路

设备数据查询是二次开发里最高频的接口调用。我给出一个实战场景：从第三方业务系统发起请求，查询某台设备最近 24 小时的温度数据，用于生成曲线报表。

public List<TemperaturePoint> queryDeviceHistory(String deviceId, long startTime, long endTime) { String url = FolarConfig.BASE_URL + "/devices/" + deviceId + "/properties/history"; Map<String, String> params = new HashMap<>(); params.put("propertyKey", "temperature"); params.put("startTime", String.valueOf(startTime)); params.put("endTime", String.valueOf(endTime)); params.put("aggregate", "AVG"); params.put("interval", "3600000"); // 按小时聚合 // 加上签名参数 Map<String, String> headers = buildAuthHeaders(params); String json = httpGet(url, params, headers); return parseTemperatureList(json); }

这里的核心逻辑是聚合参数的应用。如果你不指定aggregate和interval，平台会返回原始采样数据，比如设备每 30 秒上报一次，24 小时就有 2880 条记录，传给前端做图表不仅慢，而且没必要。指定按小时聚合后，只需要 24 条数据，前端画图又快又轻。这个思路不仅适用温度，其他属性一样适用。

再来看指令下发。设备控制是物联网项目里最容易出问题的环节，因为它是异步的。调用下发接口只是代表平台接受了你的指令，不等于设备已经执行成功。所以完整的代码逻辑应该包含三步：构建指令参数、调用下发接口、轮询任务状态。

public boolean sendDeviceCommand(String deviceId, String commandName, Map<String, Object> params) { // 第一步：构建指令请求 String url = FolarConfig.BASE_URL + "/devices/" + deviceId + "/commands"; JSONObject body = new JSONObject(); body.put("commandName", commandName); body.put("params", params); // 第二步：调用下发接口，拿到任务ID JSONObject resp = httpPost(url, body, buildAuthHeaders(null)); String taskId = resp.getString("taskId"); // 第三步：轮询任务状态，最多等待10秒 for (int i = 0; i < 20; i++) { Thread.sleep(500); JSONObject taskResp = queryTask(taskId); if ("SUCCESS".equals(taskResp.getString("status"))) { return true; } if ("FAILED".equals(taskResp.getString("status"))) { return false; } } return false; // 超时未完成 }

轮询间隔设为 500 毫秒是我测试下来的经验值。太短会增加平台压力，太长会让用户感觉到明显延迟。10 秒超时也是动态调整的，如果是控制机械臂这类动作时间长的设备，超时时间要适当延长。

3.4 Webhook 事件回调的接收与处理

事件回调的代码实现比接口调用稍微复杂一点，因为你得提供一个可以被平台访问的 HTTP 服务。Folar 的事件推送格式是 JSON，推送内容包括事件类型、设备标识、项目标识、事件产生时间和具体数据。

@RestController public class CallbackController { @PostMapping("/folar/callback") public String receiveCallback(@RequestBody String payload, @RequestHeader("X-Folar-Signature") String signature) { // 验证签名，防止伪造请求 if (!verifySignature(payload, signature)) { return "invalid signature"; } // 解析推送数据 JSONObject event = JSON.parseObject(payload); String eventType = event.getString("eventType"); String deviceId = event.getString("deviceId"); // 根据事件类型做业务处理 if ("DEVICE_OFFLINE".equals(eventType)) { handleDeviceOffline(deviceId); } else if ("ALARM_TRIGGERED".equals(eventType)) { handleAlarm(event.getJSONObject("alarmInfo")); } // 收到后务必返回成功，否则平台会重复推送 return "success"; } }

Webhook 接收方有一个重要的行为准则：处理完业务逻辑后，必须返回200 OK，响应体无所谓，平台只看状态码。如果处理失败或者超时，平台会按策略重新推送。我经历过一次事故，回调接口因为数据库连接池满了导致响应缓慢，平台那边触发了重推，结果第二天一看重复数据一大堆。所以回调处理逻辑里一定要做幂等控制，比如同一事件 ID 只处理一次。

4. 数据库结构深度拆解：业务表关联与扩展策略

4.1 核心业务表的职责划分

如果说开放接口是 Folar 的窗户，那数据库结构就是它的骨架。理解数据库结构，才能在做深度定制时心里有数。

Folar 的数据库表设计遵循物联网平台的通用范式，核心表大致可以分为四类。第一类是空间维度表，包括项目表、区域表，用来描述设备装在哪里。比如一栋楼是一个项目，楼里的每层或每个房间是区域。第二类是设备维度表，包括产品表、设备表，产品定义了设备的物模型，设备是产品的实例。第三类是数据维度表，包括属性表、事件表、告警表，存的是设备和平台的运行数据。第四类是系统维度表，包括用户表、角色表、应用表，负责权限和集成管理。

了解表与表之间的关系，比看单独某张表的结构更有用。项目表和区域表是一对多的关系；产品表和设备表是一对多；设备表和属性表是一对多；区域表和设备表通过区域 ID 关联，也就是说设备挂在区域下面，区域挂在项目下面。实际查询时，经常需要三张甚至四张表做 JOIN，才能拿到完整的业务信息。

4.2 关键数据表字段解析与扩展建议

我来拆解几张最关键的表，把字段含义讲透。

设备表（device）是查得最多的表。核心字段包括id（设备唯一标识）、product_id（所属产品）、region_id（所属区域）、status（在线状态）、last_online_time（最后在线时间）、create_time、update_time。其中status字段在 Folar 里用的是 TINYINT 类型，0 表示离线，1 表示在线，这个在用 SQL 直接查数据时要注意，不同版本的平台可能用字符串。

产品表（product）定义了设备的能力模型。它的关键字段有id、name、node_type（直连设备还是网关子设备）、create_time。产品真正的核心不在表字段里，而在属性定义和事件定义上。Folar 的产品属性通常以 JSON 格式存在一个单独的表里，描述属性的 key、名称、类型、读写权限。做二次开发时，如果你的业务需要展示产品的属性列表，直接查这个独立的物模型表会比解析 JSON 更高效。

告警表（alarm）是告警中心的数据基础。关键字段包括alarm_id（告警唯一 ID）、device_id（触发告警的设备）、alarm_type（告警类型，如阈值告警、设备离线告警）、level（告警级别）、content（告警内容）、status（处理状态）、create_time（触发时间）、handle_time（处理时间）、handler（处理人）。

这里要给一个重要的扩展建议：不要在 Folar 原生表上直接加字段。我看到过有团队为了满足客户需求，直接在 alarm 表上加了几个自定义字段，刚开始挺好用，等平台升级或者需要和官方版本做同步时，改动全被覆盖了。正确的做法是建一张自己的扩展表，用 alarm_id 和原生表做关联。比如你要做工单系统，可以建一张work_order表，里面存alarm_id、assignee、deadline、remark等字段。这样既不打乱原生表结构，又实现了业务扩展。

4.3 数据库索引优化与常见查询场景

物联网数据表有个通病：数据量增长极快。一台设备一天产生上万条属性记录，上百台设备跑一个月，数据表就是百万甚至千万级别。这时候 SQL 写不好，查询慢得让人抓狂。

Folar 在历史数据表上一般已经建好了复合索引，通常是(device_id, property_key, create_time)。这意味着你在做历史数据查询时，如果条件里有这三个字段的组合，SQL 可以走索引，速度很快。但要注意，如果查询条件里没有索引的第一个字段（device_id），即使后面两个字段都带了，索引也用不上。

我推荐三个高频查询场景的 SQL 模板。

场景一：查某台设备最近状态。

SELECT * FROM device WHERE id = 'device_001' LIMIT 1;

场景二：查某个项目下所有在线设备。

SELECT d.id, d.name, r.name AS region_name FROM device d LEFT JOIN region r ON d.region_id = r.id WHERE r.project_id = 'project_001' AND d.status = 1;

场景三：查某台设备最近 7 天的告警数量。

SELECT DATE(create_time) AS day, COUNT(*) AS cnt FROM alarm WHERE device_id = 'device_001' AND create_time >= DATE_SUB(NOW(), INTERVAL 7 DAY) GROUP BY DATE(create_time);

第三个查询在数据量大的时候，如果没有(device_id, create_time)的联合索引，会走全表扫描。所以如果是你自己的扩展表，建表时务必把常用查询字段都考虑进去，提前建立索引，否则等数据跑起来了再回头调索引，停机维护是跑不掉的。

4.4 数据迁移与历史数据导入导出的注意事项

做二次开发的软件公司，经常遇到的一个需求是：客户已经在用别的平台，需要把历史数据迁移到 Folar。这个活看起来简单，实际坑很多。

首先是数据格式的映射。旧平台的设备状态可能是字符串，Folar 里是整数；旧平台的时间戳可能是秒级，Folar 里是毫秒级。迁移前必须做好转换，否则数据进去就会出现"设备永久离线"或者"时间倒退十年"这种诡异现象。

其次是迁移工具的选择。数据量小（几百 MB）可以直接写脚本调开放接口做导入，简单直接。但数据量大（几 GB 以上）就不要调接口了，效率太低，而且容易触发接口限流。正确的做法是让平台方提供数据库层面的迁移支持，走数据库备份恢复或者中间表导入的方式。

第三是迁移后的数据校验。我习惯在迁移完成后做几组抽样校验：随机抽几个设备，对比迁移前后最后一条数据的时间戳和数据值；统计各项目下的设备数量、告警数量，与源平台核对。只有这些数据对得上，才敢给客户交付，不然上线后数据对不上，客户信任度会大打折扣。

5. 共性痛点与排查思路：二次开发避坑手册

5.1 接口调不通的五大典型原因分析

做了这么多次二次开发对接，我总结出接口调不通的常见原因，基本都是这些：

第一，Token 过期或无效。这个前面提过，最容易被忽视。解决方案是在请求拦截器里统一处理，当接口返回 401 时自动刷新 Token 并重试一次。

第二，签名校验失败。Folar 的签名要求参数按 ASCII 码升序排列，很多人排序时把请求头的参数也一起排序了，导致签名对不上。另外，有些语言对 JSON 序列化时键的顺序会做调整，也会影响签名结果。我的经验是签名用的字符串拼接必须严格按照文档来，多一个空格、少一个逗号都不行。

第三，参数格式错误。比如时间戳要求毫秒，你传了秒；分页参数要求从 1 开始，你从 0 开始。这类问题看着低级，但实际排查起来最费时间，因为没有明显的报错提示，往往是返回成功但数据为空。

第四，权限不足。应用没有配置对应项目或设备的访问权限，接口调用时返回 403。解决方法是去平台后台检查应用权限配置。

第五，接口路径拼错。听起来不太可能，但在多版本接口共存的场景下很常见。Folar 可能在版本升级后调整了接口路径，但文档没有及时更新，或者你用的是网上搜的旧版本文档。所以我强烈建议以拉孚官方最新的接口文档为准。

5.2 数据不同步与一致性问题排查逻辑

数据不同步的问题在二次开发里也经常出现。表现特征是：第三方系统里看到的设备状态和 Folar 平台上不一致，或者历史数据差了几条。

排查思路要从数据链路开始。设备数据从现场传到平台，再从平台通过接口被第三方获取，链条上的任何一环都可能出问题。我总结了一个排查顺序：先确认设备侧是否真的在上报数据，再到平台后台看原始数据是否正常入库，最后检查第三方系统是不是在调用接口时加了过期的缓存。

这里有一个容易忽略的点：Folar 的数据查询接口默认返回的是最新缓存值，而不是实时读库。也就是说，设备刚刚上报的数据，可能会有几秒钟的延迟才能通过接口查到。如果客户的业务对实时性要求很高，需要评估这个延迟是否能接受，或者调整接口的实时性参数。

另一个常见问题是分页查询导致的数据漏读。当你用分页循环拉取历史数据时，如果边拉数据边有新数据写入，可能会导致某一页数据重复或遗漏。解决方案是在拉取时用时间窗口加游标的方式，每次拉取一个固定时间范围的数据，记录当前最大时间戳，下一次从这个时间戳继续，这样即使有新数据进来也不影响。

5.3 二次开发的项目管理经验总结

最后说点技术之外的。二次开发项目能不能做好，技术只是一部分，更关键的是需求边界和变更管理。

我在接手这类项目时，第一件事就是和客户明确哪些功能平台原生已经支持，哪些是需要二次开发才能实现的。很多客户不了解平台的边界，会觉得"你们都能连设备了，为什么不能顺便做个报表"——这时候必须耐心解释哪些属于配置项、哪些属于开发项，避免免费需求膨胀成无底洞。

第二件事是搭建一个模拟环境。不要直接在客户的生产环境上做测试，一方面数据敏感，另一方面真出了问题影响生产就很麻烦。正确做法是在本地或者测试服务器部署一套 Folar 环境，用模拟设备产生数据，在这个环境上完成接口调试和联调，确认无误后再上生产。

第三件事是做好变更记录。二次开发的项目往往周期长、需求变化频繁，代码版本管理和需求变更记录要同步维护。我习惯用表格记录每一次需求变更的内容、涉及的功能点、开发状态和验证结果，这个习惯帮我在多个项目中避免了"客户说改过，但代码里完全没有"的尴尬。

6. 技术之外的几点体会

聊了这么多接口、表和代码，最后分享一点我对物联基座二次开发的整体感受。

我发现很多软件公司在选型时容易陷入两个极端：一种是什么都看不上，觉得只有从零开发才最能体现技术实力；另一种是什么都依赖基座，觉得套上平台就万事大吉。这两种态度其实都走偏了。物联基座真正带来的价值，是帮你把那些"做了没亮点、不做又不行"的基础功能省掉，让你能把人力投到客户看得见摸得着的业务价值上。

还有一点很关键：好的基座产品，接口文档和数据库结构一定是清晰的。如果你选择二次开发的平台，打开它的开发文档，发现接口没有统一规范、鉴权方式混乱、连数据库表结构都不对外提供，那就要谨慎了，因为你后续的每一次开发都可能变成和平台厂商拉锯的过程。DeepBasic Folar 在这方面做得比较厚道，开放接口的设计有章法，数据库表结构也清晰，对二次开发团队友好得多。

根据我个人的经验，现在做物联网项目，纯粹拼硬件的时代已经过去了，软件和平台的整合能力才是拉开差距的地方。善用物联基座、读懂它的接口和数据，你就等于站在别人的肩膀上做自己的事，这条路走通了，团队的交付效率和项目的利润率都会有明显提升。