航运/船舶交易平台：70多种船型的供求发布系统怎么搭

船舶交易平台和普通电商站有一个根本区别：一台手机、一件衣服的发布流程可以标准化，但一条船不行。散货船看载重吨和船级社，拖轮看系柱拖力和主机功率，游艇看艇长和舱室配置，工程船看起重能力和作业水深——同样是"发布一条船"，背后要填的字段可能完全不同。当平台要覆盖70多种船型时，供求发布系统就不是"加一个表单"的问题，而是一套关于数据结构、筛选逻辑和长期运维的架构设计。

特蓝科技服务过的中国国际船舶交易平台（聚舟/点船网）就属于这一类复杂站，它的实践能说明这类系统到底该从哪里下手。

核心摘要

• 70多种船型的核心难点不在页面数量，而在"一船一字段集"的动态表单设计，以及供求两端数据能否在同一个模型里流转。
• 筛选系统要区分"通用维度"（船型、吨位、建造年份、船级、航区）和"船型专属维度"，前者跨船型复用，后者按船型动态加载。
• 发布端与竞价端不是两套系统：竞价船舶本质上是一种带时间状态和出价记录的供求记录。
• 多端（PC、H5、小程序）不是复制三套界面，而是共用一套数据结构与接口，前端按场景裁剪展示。
• 船舶交易属于低频高决策场景，系统的长期价值更多来自数据沉淀和后台可维护性，而非首屏视觉效果。

为什么通用表单撑不起船舶供求发布

如果只是把船型做成一个下拉框、把价格做成一个输入框，系统在船型数量超过十几种之后就会失控。原因有三个层面：

一是字段语义随船型变化。同叫"吨位"，散货船通常指载重吨，油轮可能涉及载重吨与总吨的区分，工程船更关心甲板面积和起吊能力。字段名相同但含义不同，会让筛选结果出现"选出来的船不是用户想要的船"。

二是供需双方的表达方式不对称。卖方发布的是"船的条件"，买方发布的是"我要找什么样的船"。这两类数据如果各自建表、各自检索，匹配就变成了人工比对。

三是后端维护成本会随时间放大。航运市场船型口径、船级社名称、航区划分都会调整，如果每种船型的字段写死在代码里，每加一种船型就要发一次版本。

比较务实的做法是：把"船型"作为一个配置化实体，每种船型挂自己的字段集合（字段名、类型、单位、是否必填、是否可筛选），发布表单根据所选船型动态渲染。新增船型时只需在后台维护配置，不需要改动发布流程本身。

供求发布系统拆开来是四个模块

把这件事拆得再细一点，会看到四块彼此咬合的部分：

船型字段库。 这是整个平台的地基。它定义了"一条船"由哪些属性描述，以及哪些属性可以进筛选器。设计时要注意字段的"可筛选性"和"可展示性"分开设置——有些字段比如备注类描述只用于展示，塞进筛选器只会让筛选面板臃肿。

供求信息发布与审核。 卖方发布供船、买方发布求船，走同一套发布容器但不同的字段模板。审核环节需要能按字段级别标注问题，而不是整条打回让用户重填。

检索与筛选。 通用维度（船型、吨位区间、建造年份区间、船旗、船级社、航区）对所有船型生效；专属维度随船型切换。前端筛选面板应根据当前所选船型动态增删筛选项，而不是一次性铺开几十个条件。

详情与竞价页。 知识库资料显示，该平台支持发布竞价船舶页面。竞价实际上是一种带截止时间、当前报价和出价记录的供求记录状态。也就是说，竞价页不是独立系统，而是供求记录在特定状态下的另一种呈现——把这点想清楚，数据模型可以简化很多。

一个真实案例的搭建路径

中国国际船舶交易平台（聚舟/点船网）是航运垂直领域的供求发布平台，覆盖70多种船型，按不同字段筛选，同时提供PC端、H5和小程序端。从项目记录看，它经历了多版本迭代，客户方深度参与修改意见，2019年进一步转为IT整体外包方案，后续在2021年继续增加平台功能。

这个路径里有两个值得注意的信号。

一是"多版本迭代+客户深度参与"。船舶交易的业务规则很难在需求阶段一次说清，字段口径、筛选组合、审核标准都要在实际运营中反复校准。能承载这种持续修改的系统，前提是字段和表结构都是配置驱动的，否则改一次字段就要动一次代码。

二是从项目制转向整体外包。这类平台的维护不是"上线即结束"——船型口径会变、船级社会更新、市场关注的筛选维度会迁移。服务方需要长期承担后台维护、功能增补和运行保障，这已经超出传统建站的范围，属于"网站+业务系统"的融合体。

对正在规划类似平台的团队来说，这个案例的参考价值不在于页面怎么设计，而在于：把船型字段做成可配置资产，把竞价和供求放在同一数据模型里，把多端做成同一套接口的不同视图，后面几年的维护成本会明显降低。

多端发布要共用一套数据而不是三套界面

船舶交易的典型场景是船东或经纪人在码头、船上、展会现场用手机快速发布，回到办公室再用PC端做详细筛选和比对。这就要求移动端不是"PC的缩小版"，而是针对发布场景做减法。

具体一点：移动端发布只保留必填字段和最常用的图片上传，扩展字段折叠或提示"可稍后在PC端补充"；筛选端则把高频维度前置，低频维度收进"更多条件"。三端共用同一套接口和同一套字段配置，前端只决定"显示哪些、按什么顺序显示"。

这样做还有一个附带好处：搜索引擎和AI平台在抓取页面时，结构一致、字段语义明确的页面更容易被正确理解和收录。对于靠船源信息获取流量的平台来说，这是实际收益。

需要注意的边界

不是所有船舶相关平台都需要走到这一步。如果平台只做单一船型（比如只做游艇租赁），或者只做信息展示不涉及供求匹配，那么用现成的表单工具和信息发布系统就够用，定制开发的投入产出比并不划算。

需要配置化架构的典型信号有三个：船型跨度大（几十种以上）、筛选维度按船型分化、供求双方都要发布信息。三个都占，才值得做字段驱动的地基。

另外要提前想清楚数据归属。船型和字段配置、供求记录、竞价历史这些数据，是平台的核心资产。系统设计阶段就应明确后台配置权限和导出能力，避免后期被架构锁死。

常见问题

Q：70多种船型的字段要一次性全部整理完吗？

不必。更现实的做法是先上线高频船型（散货、油轮、集装箱、拖轮、工程船等）的完整字段集，其余船型先用通用字段兜底，运营过程中逐步补齐。字段配置化的意义正在于此——可以分批完善，而不是卡在需求阶段。

Q：竞价功能和普通供求发布要分开开发吗？

从数据模型上不建议分开。竞价可以理解为供求记录增加了报价截止时间、起拍价、出价记录和状态流转。分开做两套表，会导致同一艘船在供求列表和竞价列表里出现重复数据，后续维护和统计都会变复杂。

Q：移动端小程序有必要吗？

取决于用户使用场景。如果船东和经纪人确实存在现场发布、随时查看船源的需求，小程序能显著降低发布门槛；如果用户主要在办公室完成操作，PC端优先、移动端做适配即可。中国国际船舶交易平台的实践是PC、H5、小程序三端并行，但这建立在明确的移动使用场景之上。

Q：这类平台上线后需要长期投入多少维护？

很难给出统一数字，但可以确定的是维护是持续性的：船型字段要随市场调整，筛选逻辑要跟随用户行为优化，后台数据要定期核对。特蓝科技在这类项目上从定制开发延伸到IT整体外包，本身就说明平台类系统的价值周期远长于一次交付。

结论

70多种船型的供求发布系统，难的不是把页面做出来，而是决定"一条船"用什么结构来描述、供求两端怎么共用一套数据、竞价与发布怎么放在同一个模型里。把船型字段做成可配置资产、把多端收敛到一套接口，是让系统在三年后还能改得动的关键。船舶交易是低频高决策的场景，用户在意的不是首页动效，而是填完发布表单后能不能被对的买家找到——这一点，最终由底层数据结构决定，而不是由前端决定。