1703879115
·可以使用Solidity的导入命令声明合约相关内容。truffle将用正确的顺序编译合约，并在必要时自动接入库。必须指明相关内容与当前Solidity文件之间的关系，开头是“./”或者“../”。
1703879116
1703879117
1703879118
truffle 3.1.2版本使用编译器版本0.4.8。ruffle目前不支持更换编译器版本，所以是固定的。
1703879119
1703879120
1703879121
1703879122
1703879123
区块链项目开发指南 [:1703875396]
1703879124
区块链项目开发指南 8.4.4 配置文件
1703879125
1703879126
truffle.js是用于配置项目的JavaScript文件。该文件可以执行为项目创建配置所需的任何代码。它必须导出一个代表项目配置的对象。文件默认内容如下：
1703879127
1703879128
1703879129
1703879130
1703879131
该对象可以包含多种属性，但最基础的属性是networks。该属性指明哪个网络对部署可用，以及与每个网络交互时的特定交易参数（例如gasPrice、from、gas等）。默认gasPrice是100000000000，gas是4712388，from是以太坊客户端中的第一个可用合约。
1703879132
1703879133
可以随意指定网络数量。继续修改配置文件：
1703879134
1703879135
1703879136
1703879137
1703879138
上述代码定义了development和live两个网络。
1703879139
1703879140
1703879141
在Windows上使用Prompt命令时，默认配置文件名可能导致与可执行truffle的冲突。如果遇到这种情况，推荐使用Windows PowerShell或者Git BASH，因为这些shells没有这种冲突。或者可以将配置文件重命名为truffle-config.js，以避免冲突。
1703879142
1703879143
1703879144
1703879145
1703879146
区块链项目开发指南 [:1703875397]
1703879147
区块链项目开发指南 8.4.5 部署合约
1703879148
1703879149
即使是最小的项目，也将与至少两个区块链交互：一个在开发人员的机器上，例如ethereumjs testrpc；另一个代表应用最终被部署到的网络，例如以太坊主网络或者私有联盟网络）。
1703879150
1703879151
因为合约抽象运行时自动检测网络，这意味着只需要部署应用或者前端一次。当应用运行时，正在运行的以太坊客户端将决定使用哪些artifacts，这将使应用非常灵活。
1703879152
1703879153
如果JavaScript文件中包含向以太坊网络部署合约的代码，那么此类文件称为移植文件。这些文件负责分步骤部署任务，它们假定部署需求将随时间推进而改变——随着项目的推进，用户会创建新的migrations脚本以在区块链上继续。之前运行移植的历史通过一个特殊的Migrations合约记录在区块链上。如果用户已经看见合约内容和build/contracts目录，或许就已经注意到了Migrations合约。除了正常的编译或发布之外，不要修改这些合约。
1703879154
1703879155
1.移植文件
1703879156
1703879157
在migrations目录中，文件名的前缀是数字，例如1_initial_migration.js和2_deploy_contracts.js。前缀数字是为了记录移植是否能成功运行。
1703879158
1703879159
Migrations合约在last_completed_migration中存储一个数字，该数字与migrations文件夹中最后应用的移植脚本相匹配。Migrations合约总是第一个被部署。编号方式是x_script_name.js，x从1开始。应用合约一般从2开始。
1703879160
1703879161
这样，Migrations合约中就存储了最后部署的应用脚本的序号，truffle将不会再次运行这些脚本。另外，应用未来可能需要部署修改过的或新的合约。为此，需要创建一个新的脚本，其序号表示需要进行的步骤。待再次运行之后，它们将不会再次运行。
1703879162
1703879163
2.编写移植文件
1703879164