联盟链和跨端应用放在同一个课程项目里时，很容易被技术名词带着走：链上存证、数字藏品、智能合约、一次开发多端运行。真正动手以后，最先遇到的却是节点、权限、接口和页面状态这些具体问题。技术选择只有放回限制条件，才有讨论的意义。
先说清楚链解决什么
如果系统只需要记录一张可以由单一机构修改的表，普通数据库更简单，也更容易备份和查询。联盟链适合多个参与方需要共同确认记录、又不希望由某一方独占写权限的场景。它并不会自动产生信任，也不会让业务规则脱离组织和法律。
在项目里，我会先把链上和链下的数据分开。交易状态、时间戳和必要的摘要可以放到链上，图片、描述和搜索字段放在普通存储里。若把大文件直接写入链，成本、查询和迁移都会变得笨重；若只保存一个哈希，则要明确谁负责保管原始文件，以及文件丢失时如何处理。
节点和合约只是基础设施
选择 FISCO BCOS 这类联盟链框架以后，开发工作并没有变成“写几个合约”。节点启动、证书、组织权限、端口和版本都需要被记录。环境问题往往比合约本身更先暴露：依赖版本不一致，某个服务没有启动，或是接口虽然返回了结果，状态却没有正确提交。
合约应该尽量小，把可验证的规则放在链上，把展示和搜索留给应用层。发行、转移和查询各自定义输入、输出和失败状态，前端不能只根据按钮颜色判断成功。每次交易都要保存交易哈希，并提供查询入口，用户才能知道“提交”之后到底发生了什么。
跨端不是一套代码到处一样
uni-app 可以减少页面结构的重复，但 H5、微信小程序和不同版本的 Android 仍然有各自的能力边界。布局、权限、文件选择、网络请求和长列表都可能出现差异。条件编译可以解决一部分问题，却也会让同一个功能分成几套路径。
我会把平台差异集中在适配层，并为每个平台留下最小可运行的检查。不要等到最后一次打包才发现某个组件在目标平台不可用。跨端的价值是减少重复劳动，不是承诺所有行为完全一致。
认证与去中心化的矛盾
面向真实用户的系统往往需要登录、权限和合规审核。实名认证、账号状态和内容审核这些要求，并不会因为底层使用区块链而消失。把“去中心化”写进标题，不代表应用就可以忽略现实中的责任边界。
这个项目让我重新看待技术叙事。链上记录可以提供一种可验证的历史，但它解决不了原始内容是否真实、账号是否被盗、用户是否理解交易规则等问题。跨端框架可以降低页面重复，却不会替你处理平台差异。
复盘时我留下了一张更具体的清单：哪些事实需要共同确认，哪些数据应该留在链下，节点和权限怎样恢复，平台差异怎样测试，用户遇到失败时如何取回状态。把这些问题回答清楚，技术选型才不只是项目封面上的名词。