Hyperledger Fabric fabric-samples中两应用示例的差异与使用问题

两个示例的设计定位、适用场景与使用时机 #

• application-javascript 是旧版Fabric SDK编程模型的遗留参考示例，对应Fabric 2.4版本之前的低层级客户端交互逻辑。你实际跑代码就能发现，这个示例需要开发者手动处理网络节点配置、交易提案分发、签名收集、交易提交轮询等全流程细节，样板代码极多。它的存在完全是为了给存量老项目做参考：如果你手上维护的是2022年之前基于旧版JS SDK开发的Fabric应用，做功能迭代、问题排查的时候可以参照这个示例的写法，全新开发的项目不建议参考这个示例的实现逻辑。
• application-gateway-go 是Fabric 2.4版本后正式GA的Gateway编程模型官方标准示例。Gateway模型把原来客户端要做的交易路由、节点通信、提交状态监听等通用逻辑全部下沉到了Peer节点内置的Gateway服务上，客户端代码只需要聚焦业务逻辑本身，代码量比旧SDK模型少60%左右，出错概率也低很多。这个示例的定位是给所有新开发的Go技术栈Fabric应用提供写法参考，只要是从零搭建新的Fabric业务系统、用Go写链下服务的场景，直接照着这个示例的结构写就行，是目前官方主推的客户端实现范式。

为什么官方没有提供独立的JavaScript版本Gateway示例 #

不存在官方不支持JS版本Gateway能力的问题，核心是仓库维护策略和优先级的原因：

• 首先是迭代节奏问题：Gateway模型正式上线初期，官方维护团队优先把生产环境使用率最高的Go、Java两个后端技术栈的Gateway示例放到了fabric-samples仓库，JS/TS版本的Gateway SDK虽然同步发布，但当时没来得及抽成独立示例目录放到samples根路径下。
• 其次是维护效率的考虑：JS/TS生态本身版本迭代速度快，依赖更新频繁，官方没有把JS版本的Gateway示例放在fabric-samples仓库，而是直接把对应示例整合到了JS SDK本身的代码仓库和发布包内，跟着SDK版本同步更新，维护效率更高，不少开发者只翻fabric-samples根目录就误以为官方没有提供JS版本的Gateway实现。
• 实际使用上，JS版本的Gateway SDK接口逻辑和Go版本完全对齐，核心流程都是「加载身份证书→初始化网关连接→获取对应通道的合约实例→调用查询/提交交易接口」，照着Go版本的Gateway示例流程改写成JS语法即可，没有功能差异。

内容的提问来源于stack exchange，提问作者Alankrit010