路线 3：DApp 开发者

本路线可以作为在 TRON 上开发 DApp 的起点，适合希望逐步了解智能合约如何与前端配合的开发者。

可以从这条路线了解什么

这条路线从一个基础示例出发，依次介绍 TRON DApp 的主要组成和常见开发顺序：测试与部署 智能合约、通过 TronLink 请求用户授权，以及查询 交易结果 和 合约事件。

路线以去中心化图书馆为贯穿示例。在这个示例中，图书所有者可以上架图书并设置每日租金；其他用户可以浏览书目，并通过 TronLink 支付测试 TRX 完成租借。这个示例把合约开发、资源成本、钱包授权、前端调用和链上状态处理串联成一条完整流程，便于理解各环节之间的关系。

如果希望一边阅读一边实践，可以跟随各阶段的实践任务，逐步搭建一个运行在 Shasta 测试网上的基础 DApp 原型。这个原型主要用于熟悉开发流程。面向生产环境的架构设计、安全审计和上线准备，还需要结合具体项目继续完善。

开始前不必掌握所有相关概念。可以先通过下方概览了解各阶段的重点，再按照文档逐步实践。遇到不熟悉的术语或错误时，可以回到推荐阅读补充所需信息。

路线概览

开始前

开始实践前，建议先了解账户、交易和测试网等区块链基础概念。如果尚不熟悉，可以先从 路线 0：完全初学者 开始。完成阶段实践还需要具备 JavaScript 和 HTML/CSS 基础，并能够阅读和修改简单的 Solidity 合约。从以太坊生态迁移而来的开发者，可以重点阅读 TRON 与 Ethereum — 核心对比、 资源成本：最大的差异 和 智能合约迁移。

本路线主要梳理各阶段的核心知识。实战：构建一个 Web3 应用 提供图书馆项目的合约、自动化测试、Shasta 部署检查、基础前端和事件同步代码；各阶段的其他链接用于补充相关概念、接口语义和安全注意事项。

确定性合约测试可以在隔离的本地环境完成；所有公共网络的账户、Endpoint、部署、调用和结果查询都使用 Shasta。部署私钥只提供给本地部署工具或受控签名环境，终端用户的授权则由 TronLink 完成。

路线阶段

1. 了解 DApp 交互流程并准备开发环境

一个 DApp 的交互通常从浏览器开始。TronLink 向应用提供当前账户和网络信息，并负责向用户请求授权与签名确认；TronWeb 帮助前端构建调用并与节点交互；智能合约则负责执行链上逻辑。先了解这条调用链，有助于区分不需要签名的读取、需要用户确认的写入，以及由部署脚本使用的部署账户。

本路线使用 TronBox 管理合约的编译、测试和部署，并以 Shasta 作为公开测试环境。部署账户的私钥只提供给本地部署工具，终端用户的交易授权则由 TronLink 完成，两者承担不同的职责。

推荐阅读

1. 智能合约简介 — 什么是智能合约

   读到“智能合约的局限性”即可，用于理解合约在 DApp 中负责什么；TRON 特有背景可在需要专有能力时再读。

2. DApp 钱包集成 — 集成方案选型对比

   用于区分 TronWallet Adapter 与直接集成 TronLink；图书馆教程使用直接集成方式，生产项目可根据多钱包需求另行选型。

3. 与合约交互 — 读取与写入对比一览

   只读对比表，理解读取、写入、签名和资源之间的区别；具体调用留到阶段 4。

4. 智能合约快速通道 — 配置 Shasta 网络

   用于核对 TronBox 的 Shasta 配置和私钥注入方式；编译与部署操作留到后续阶段。

阶段实践

图书馆项目从开发环境初始化和 Shasta 网络配置开始。按照 实战：构建一个 Web3 应用 — 准备工作 和 创建项目 完成项目初始化，再准备 Shasta 配置，但暂不部署。部署账户的私钥只通过受控环境提供，不应写入源码、前端代码或版本库。

进入合约开发前：先确认 TronBox 项目已经完成初始化，并保留本地测试和 Shasta 部署配置。

2. 开发并测试应用合约

开发应用合约，通常从把应用需求转换为可以验证的合约逻辑开始，并逐步明确合约的读写边界、业务规则和测试方法。图书馆示例中的合约只实现应用需要的核心能力：图书所有者上架图书，用户查询书目并按天支付租金，合约记录租借人和到期时间。查询不会改变链上状态；上架和租借会修改状态，其中租借还涉及付款和向图书所有者转账。

在实现这些功能时，还需要明确几项规则，例如图书是否存在、租期是否有效、付款金额是否正确，以及一本书在租借期间能否再次出租。事件可以为图书上架和租借留下链上记录，自动化测试则可以协助确认正常流程和这些规则是否符合预期。

推荐阅读

1. TRON 上的 Solidity — 编译器版本支持 和 编写与编译 — 编译合约

   用于核对 Solidity 版本、优化配置和编译产物；未使用的 TRC-10、质押与投票扩展可以跳过。

2. 智能合约安全 — 重入攻击 和 拒绝接收 TRX 导致的 DoS

   用于检查租金转移前后的状态顺序，以及图书所有者为合约地址时的失败风险；其他攻击按实际合约能力选读。

3. 事件日志 — 定义与触发事件

   用于核对图书上架和租借事件的参数与触发位置；链下事件消费留到阶段 5。

4. 实战：构建一个 Web3 应用 — 在本地测试合约

   使用教程中的测试文件验证图书上架、查询、租金到账和事件，并覆盖付款金额错误、图书不存在、租期越界和重复租借。

阶段实践

图书馆项目中的合约实践包含三个任务：

1. 在阶段 1 初始化的 TronBox 项目中，按照 实战：构建一个 Web3 应用 — 编写智能合约，实现图书上架、查询和租借。
2. 按照 在本地测试合约 启动 TRE 并运行自动化测试，先验证上架、查询、租借、租金到账和事件。
3. 核对付款金额错误、图书不存在、租期越界和重复租借等失败场景。

进入部署阶段前：保留通过测试的合约源码和编译配置，下一阶段将使用这些内容部署到 Shasta。同时保留测试代码和测试结果，以便在部署前核对。

3. 将合约部署到 Shasta

从本地测试过渡到链上部署，需要把经过验证的合约部署到公开测试网，并确认链上的部署结果能够支持后续调用。本地测试只说明合约在已覆盖的输入下是否按预期工作，不能代替对部署交易和链上合约的检查。

在图书馆示例中，部署将继续使用上一阶段的合约源码和编译配置，以取得 Shasta 合约地址，并观察公开测试网上的资源消耗和交易结果。

部署和写入调用会消耗 Bandwidth 和 Energy，账户可用资源和 fee_limit 设置都会影响交易能否完成。广播成功只说明节点已经接收交易，并不代表合约执行成功。部署后还需要检查执行结果，在不依赖前端的情况下完成基本读写调用和合约源码验证。

推荐阅读

1. 资源模型 — 能量 和 FeeLimit 与能量成本 — fee_limit 的本质作用

   用于了解部署与写入调用的 Energy 成本，以及 fee_limit 作为预算上限的作用；完整动态能量策略可在成本异常时再读。

2. 部署 — 准备工作 和 验证部署是否成功

   用于核对部署账户、目标网络、编译产物和部署结果；页面使用 TronIDE 演示时，只复用字段和验收语义。

3. 与合约交互 — 读取与写入对比一览 和 合约源码验证 — 分步验证流程

   在接入前端前完成一次读取和一次写入，再使用与部署完全一致的源码、编译器和优化配置进行验证。

阶段实践

图书馆合约沿用上一阶段通过测试的源码和编译配置。按照 实战：构建一个 Web3 应用 — 部署到 Shasta 完成部署，并保存部署 txID 和合约地址。

继续按照 检查并验证部署结果 检查交易收据，完成一次读取、一次写入和源码验证。

接入前端前：记录通过基本读写检查的 Shasta 合约地址、所属网络和部署交易。下一阶段将使用这些信息创建合约实例。

4. 通过 TronLink 连接用户与合约

前端接入阶段关注如何安全地读取合约并提交写入交易，重点包括钱包连接、账户与网络校验，以及只读调用和写入交易之间的区别。

在图书馆示例中，前端使用上一阶段取得的合约地址创建合约实例并展示链上书目。连接 TronLink 时，前端需要读取当前账户和网络；上架或租借会修改链上状态，因此需要请求用户确认交易。

前端还需要考虑钱包尚未安装、用户拒绝授权、网络不匹配，以及账户或网络发生变化等情况。读取书目不需要用户签名；上架和租借则需要提交写入交易。交易提交后可以保存返回的 txID，但不能仅凭这个结果显示上架或租借成功。

推荐阅读

1. DApp 钱包集成 — 方案二：直接集成 TronLink

   继续阅读 window.tron Provider、核心接口映射和 Chain ID 对照表，用于理解教程的直接集成方式；需要多钱包时再评估 TronWallet Adapter。

2. 与合约交互 — 读取方法 和 写入方法

   只选择前端实际使用的 TronWeb 示例，区分 .call() 与 .send()；HTTP API 示例不是当前前端的前置。

阶段实践

图书馆前端使用上一阶段保存的 Shasta 合约地址创建合约实例。按照 实战：构建一个 Web3 应用 — 创建前端页面 和 连接 TronLink 并调用合约，实现书目浏览、图书上架和付费租借。同时处理钱包未安装、拒绝授权、网络不匹配和账户或网络变化等情况。

处理链上结果前：下一阶段将使用每笔写入交易的 txID 查询链上结果。进入下一阶段前，确认前端已经保存这些 txID，并且没有把交易提交状态显示为业务成功。

5. 根据链上结果更新应用状态

交易提交后，开发重点转向如何判断执行结果，并使页面状态与链上状态保持一致。取得 txID 并不是一次写入操作的终点，而是结果确认的开始。节点接收交易不代表交易已经进入区块，交易进入区块也不代表合约执行成功。应用需要继续查询执行结果和固化状态，再根据查询结果决定页面应显示成功、失败还是暂时无法确认。

当前用户发起的写入可以通过交易收据判断执行结果。合约事件可以帮助应用发现其他账户触发的图书上架或租借变化。查询到事件后，应用需要重新读取合约状态，让页面以链上状态作为最终依据。事件查询还需要考虑重复结果、分页和查询游标。

推荐阅读

1. 确认语义 — 状态语义速查

   继续阅读“交易本体不等于执行收据”和“最新链头不等于已固化状态”，用于区分钱包拒签、节点接收、执行结果、固化和暂时未知。

2. 广播与 RPC 错误 — 交易广播成功但始终未打包上链 和 智能合约异常排查 — REVERT

   用于处理资源不足、REVERT、RPC 超时和暂时无法确认。结果未知时继续查询原 txID，不能立即创建另一笔上架或付款交易。

3. 监听合约事件 和 事件日志 — 链下消费事件的常用模式

   图书馆教程已经查询 BookAdded 和 BookRented 并在收到事件后重新读取合约状态；Recipe 进一步说明分页、查询游标和持久化去重。

阶段实践

按照 实战：构建一个 Web3 应用 — 根据交易结果更新页面状态 使用保存的原 txID 查询 Shasta 已固化收据，只有明确执行成功后才更新当前操作状态；查询超时或暂时无结果时保持未知并继续查询。

按照 通过合约事件同步状态 查询 BookAdded 和 BookRented 事件，收到事件后重新读取相关图书。结合事件 Recipe 补充分页、查询游标和持久化去重，随后按照 运行 DApp，使用图书所有者账户和租借账户运行完整流程。

验证状态处理结果：先检查页面是否根据已固化的交易执行结果更新当前操作状态。发现图书上架或租借事件后，再确认页面是否重新读取链上数据。最后测试用户拒签、Energy 不足、合约执行失败和暂时无法确认等情况，确认页面能够提供准确反馈，并避免重复创建上架或付款交易。

后续实践与扩展

实战：构建一个 Web3 应用 提供贯穿整条路线的去中心化图书馆项目，包括合约、自动化测试、Shasta 部署检查、基础前端、交易结果处理和事件同步。事件分页、游标持久化以及更完整的生产安全与运行保障仍需根据项目要求继续补充。

如果只完成了其中一部分，也可以先保留当前阶段的代码、配置和测试结果，之后再从相应阶段继续。初次接触 DApp 开发时，不需要一次完成所有扩展内容。

基础应用能够按预期运行后，可以根据项目需要增加分页和搜索功能。如需处理更大规模的事件和历史数据，可以阅读 RPC 与索引器提供商 — 数据索引器与中间件服务；如需了解合约升级，则可以阅读 升级智能合约 — 引入合约升级的架构弊端。

如果某个阶段仍然无法继续，请 提交路线反馈，注明“路线 3”、当前阶段、工具版本、Shasta Endpoint、合约地址、原 txID、已经完成的步骤和实际错误信息；不要提交私钥、助记词、API Key、生产账户信息或未公开漏洞细节。