引言

Solidity是一种合约导向编程语言，用于编写智能合约，运行在Ethereum虚拟机（EVM）上。本文档将为您介绍Solidity的基本语法和概念，帮助您快速上手智能合约开发。

合约结构

在 Solidity 中，合约类似于面向对象编程语言中的类。 每个合约中可以包含 状态变量、 函数、 函数修饰器、事件、 结构类型、 和 枚举类型 的声明，且合约可以从其他合约继承。

状态变量

状态变量是永久地存储在合约存储中的值。

1
2
3
4
5
6

pragma solidity ^0.4.0;

contract SimpleStorage {
    uint storedData; // 状态变量
    // ...
}

有效的状态变量类型参阅 类型 章节， 对状态变量可见性有可能的选择参阅 可见性和 getter 函数 。

函数

函数是合约中代码的可执行单元。

1
2
3
4
5
6
7

pragma solidity ^0.4.0;

contract SimpleAuction {
    function bid() public payable { // 函数
        // ...
    }
}

函数调用 可发生在合约内部或外部，且函数对其他合约有不同程度的可见性（ 可见性和 getter 函数）。

函数修饰器

函数修饰器可以用来以声明的方式改良函数语义（参阅合约章节中 函数）。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

pragma solidity ^0.4.22;

contract Purchase {
    address public seller;

    modifier onlySeller() { // 修饰器
        require(
            msg.sender == seller,
            "Only seller can call this."
        );
        _;
    }

    function abort() public onlySeller { // Modifier usage
        // ...
    }
}

事件

事件是能方便地调用以太坊虚拟机日志功能的接口。

1
2
3
4
5
6
7
8
9

pragma solidity ^0.4.21;
contract SimpleAuction {
    event HighestBidIncreased(address bidder, uint amount); // 事件

    function bid() public payable {
        // ...
        emit HighestBidIncreased(msg.sender, msg.value); // 触发事件
    }
}

有关如何声明事件和如何在 dapp 中使用事件的信息，参阅合约章节中的 事件。

结构类型

结构是可以将几个变量分组的自定义类型（参阅类型章节中的 结构体）。

1
2
3
4
5
6
7
8
9
10

pragma solidity ^0.4.0;

contract Ballot {
    struct Voter { // 结构
        uint weight;
        bool voted;
        address delegate;
        uint vote;
    }
}

枚举类型

枚举可用来创建由一定数量的“常量值”构成的自定义类型（参阅类型章节中的 枚举类型）。

1
2
3
4
5

pragma solidity ^0.4.0;

contract Purchase {
    enum State { Created, Locked, Inactive } // 枚举
}

类型

Solidity 是一种静态类型语言，这意味着每个变量（状态变量和局部变量）都需要被指定类型。 Solidity 提供了几种基本类型，可以用来组合出复杂类型。

值类型

以下类型之所以被称为值类型，是因为它们的变量总是通过值传递， 即在用作函数参数或赋值时总是被复制。

布尔类型

bool ：可能的取值为常数值 true 和 false。

运算符：

• ! (逻辑非)
• && (逻辑与, “and”)
• || (逻辑或, “or”)
• == (等于)
• != (不等于)

运算符 || 和 && 都遵循同样的短路（ short-circuiting ）规则。 就是说在表达式 f(x) || g(y) 中， 如果 f(x) 的值为 true / false ， 那么 g(y) 就不会被执行，即使会出现一些副作用。

整型

int / uint: 分别表示有符号和无符号的不同位数的整型变量。 关键字 uint8 到 uint256 （无符号整型，从 8 位到 256 位）以及 int8 到 int256， 以 8 位为步长递增。 uint 和 int 分别是 uint256 和 int256 的别名。

运算符：

• 比较运算符： =， > （返回布尔值）
• 位运算符： &， |， ^ (异或)， ~ (位取反)
• 移位运算符： > （右移）
• 算数运算符： +， -， 一元运算 - （只适用于有符号的整数）， *， /， % (取余)， ** (幂)

对于一个整数类型 X，您可以使用 type(X).min 和 type(X).max 来访问该类型代表的最小值和最大值。

定长浮点型

警告. Solidity 还没有完全支持定长浮点型。可以声明定长浮点型的变量， 但不能给它们赋值或把它们赋值给其他变量。↩

fixed / ufixed：表示各种大小的有符号和无符号的定长浮点型。 在关键字 ufixedMxN 和 fixedMxN 中， M 表示该类型占用的位数， N 表示可用的小数位数。 M 必须能整除 8，即 8 到 256 位。 N 则可以是从 0 到 80 之间的任意数。 ufixed 和 fixed 分别是 ufixed128x18 和 fixed128x18 的别名。

1
2
3
4

fixed constant PI = 3.14159265;
fixed a = 1.2;
ufixed constant PI = 3.14159265;
ufixed a = 1.2;

运算符：

• 比较运算符： =， > （返回值是布尔型）
• 算术运算符： +， -， 一元运算 -， *， /， % (取余数)

地址类型

地址类型有两种大致相同的类型：

• address: 保存一个20字节的值（一个以太坊地址的大小）。
• address payable: 与 address 类型相同，但有额外的方法 transfer 和 send。

这种区别背后的想法是， address payable 是一个您可以发送以太币的地址， 而您不应该发送以太币给一个普通的 address，例如，因为它可能是一个智能合约， 而这个合约不是为接受以太币而建立的。

1
2

address addr = 0x690B9A9E9aa1C9dB991C7721a92d351Db4FaC990;
address payable addr_pay = payable(0x8306300ffd616049FD7e4b0354a64Da835c1A81C);

运算符：

• = 和 >

定长字节数组

值类型 bytes1, bytes2, bytes3, …, bytes32 代表从1到32的字节序列。

1
2
3

bytes32 public _byte32 = "MiniSolidity";

bytes1 public _byte = _byte32[0];

运算符：

比较运算符：<=， <， ==， !=， >=， > （返回布尔型）

• 比较运算符： =， > (返回 bool)
• 位运算符： &， |， ^ （按位异或）， ~ （按位取反）
• 移位运算符： > （右移位）
• 索引访问： 如果 x 是 bytesI 类型，那么当 0 <= k < I 时， x[k] 返回第 k 个字节（只读）。

移位运算符以无符号的整数类型作为右操作数（但返回左操作数的类型）， 它表示要移位的位数。有符号类型的移位将产生一个编译错误。

成员变量：

• .length 表示这个字节数组的长度（只读）.

枚举类型

枚举是在 Solidity 中创建用户定义类型的一种方式。 它们可以显式地转换为所有整数类型，和从整数类型来转换，但不允许隐式转换。 从整数的显式转换在运行时检查该值是否在枚举的范围内，否则会导致 异常。 枚举要求至少有一个成员，其声明时的默认值是第一个成员。 枚举不能有超过256个成员。

数据表示与 C 语言中的枚举相同。选项由后续的从 0 开始无符号整数值表示。

使用 type(NameOfEnum).min 和 type(NameOfEnum).max 您可以得到给定枚举的最小值和最大值。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

// SPDX-License-Identifier: GPL-3.0
pragma solidity ^0.8.8;

contract test {
    enum ActionChoices { GoLeft, GoRight, GoStraight, SitStill }
    ActionChoices choice;
    ActionChoices constant defaultChoice = ActionChoices.GoStraight;

    function setGoStraight() public {
        choice = ActionChoices.GoStraight;
    }

    // 由于枚举类型不属于ABI的一部分，因此对于所有来自 Solidity 外部的调用，
    // "getChoice" 的签名会自动被改成 "getChoice() returns (uint8)"。
    function getChoice() public view returns (ActionChoices) {
        return choice;
    }

    function getDefaultChoice() public pure returns (uint) {
        return uint(defaultChoice);
    }

    function getLargestValue() public pure returns (ActionChoices) {
        return type(ActionChoices).max;
    }

    function getSmallestValue() public pure returns (ActionChoices) {
        return type(ActionChoices).min;
    }
}

函数类型

函数类型是一种表示函数的类型。可以将一个函数赋值给另一个函数类型的变量， 也可以将一个函数作为参数进行传递，还能在函数调用中返回函数类型变量。

类似的格式如下

1

function <function name> (<parameter types>) {internal|external|public|private} {modifier} [pure|view|payable] [returns (<return types>)]

引用类型

在 Solidity 中，相比于值类型，引用类型更复杂，通常包括占用更多内存的数组和结构体。当处理这些复杂的引用类型时，需要谨慎考虑它们的数据位置。

所有引用类型（如数组和结构体）都具有一个 “数据位置” 属性，指明数据是存储在内存中还是存储中。大多数情况下，数据位置有默认值，但可以通过在类型名后加 storage 或 memory 来显式指定。

• memory：用于临时存储，数据在执行完后会被销毁。
• storage：用于持久保存，数据会永久保存，直到被修改或删除。
• calldata：只读，常用于存储外部函数的参数。

默认数据位置：

• 函数参数（包括返回参数）的默认位置是 内存 (memory)。
• 局部变量的默认位置是 存储 (storage)。
• 状态变量的数据位置强制为 存储 (storage)。

示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

// SPDX-License-Identifier: GPL-3.0
pragma solidity ^0.8.0;
contract C {
    // 我们选择使用string类型，这里使用storage。
    // 需要注意的是，在该位置时默认数据为storage，这个可以忽略
    // 这是因为状态变量不需要指定数据位置，默认为storage
    string public x;
    // memoryArray 的数据存储位置是 memory
    // 我们也可以给他的数据存储位置为 calldata
    function f(string memory memoryString) public{
      // memoryString = "hello"
       x = memoryString;
    }
    // calldata
    // memory
    function g(string calldata ) external {
    }
    // storage
    function h(string storage ) internal  {
    }

}

数据位置的重要性

数据位置影响赋值行为：

• 在 存储 (storage) 和 内存 (memory) 之间赋值会创建新的拷贝。
• **存储 (storage)**进行 赋值时，只会传递引用，不会创建新副本。
• 内存 (memory) 之间的赋值通常不会创建新副本，因为它们共享相同的数据。

总结

• 强制指定的数据位置：
  外部函数,也就是external，形参的数据位置可以为 calldata，也可以为memory，但是绝对不是storage，public同理。

• 状态变量为 storage，也可以指定函数形参的数据位置为storage，不过基本上只能在内部函数internal执行。

• 函数参数（包括返回参数）为 memory，也可以为calldata。

• 其他局部变量为 storage。

数组

Solidity 支持两种类型的数组：固定长度数组和动态数组。

一个元素类型为 T，固定长度为 k 的数组可以声明为 T[k]， 而动态数组声明为 T[]。

固定长度数组:uint[5],uint[2][5] …

动态数组:uint[],uint[][5] …

示例

1
2
3
4

uint[5] a = [1,2,3,4,5]; // 5 element array
uint[5] b;
uint[] c;
uint[] d = [1,2,3,4,5];

索引: 对元素中的一个数据进行定位，数组索引从0开始，访问一个数组中的其中一个元素，访问时的下标顺序与声明时相反。访问一个超过它的末端的数组会导致一个失败的断言。

示例

1
2
3
4
5
6

function returnOne() public view returns (uint){
    return d[0];//返回第一个元素
}
function returntwo() public view returns (uint){
    return d[1];//返回第二个元素
}

数组成员:

• length:
  数组有 length 成员变量表示当前数组的长度。一经创建， 内存memory数组的大小就是固定的（但却是动态的，也就是说，它依赖于运行时数组的参数）。
  1
  2
  3
  function returnLength() public view returns (uint){ return d.length;}
• push():
  动态存储数组和 bytes （不是 string ）有一个叫 push() 的成员函数， 您可以用它在数组的末尾追加一个零初始化的元素。它返回一个元素的引用， 因此可以像 x.push().t = 2 或 x.push() = b 那样使用。
  1
  2
  3
  function add(uint x) public{ c.push();}
• push(x):
  动态存储数组和 bytes （不是 string ）有一个叫 push(x) 的成员函数， 您可以用它在数组的末端追加一个指定的元素。该函数不返回任何东西。
  1
  2
  3
  function add(uint x) public{d.push(x);}
• pop():
  动态存储数组和 bytes （不是 string ）有一个叫 pop() 的成员函数， 您可以用它来从数组的末端移除一个元素。 这也隐含地在被删除的元素上调用 delete。该函数不返回任何东西。

1
2
3

function del() public{
    d.pop(); //删除末尾
}

创建内存数组:具有动态长度的内存数组可以使用 new 操作符创建。 与存储数组不同的是，不可能 调整内存数组的大小（例如， .push 成员函数不可用）。 您必须事先计算出所需的大小，或者创建一个新的内存数组并复制每个元素。

正如Solidity中的所有变量一样，新分配的数组元素总是以 默认值 进行初始化。

示例

1
2
3
4
5
6

function createMemoryArray(uint len) public view returns (uint[] memory){
       uint[] memory arr = new uint[](len); //创建长度为len的内存数组
       arr[0] = 1;
       arr[1] = 2;
       return arr;
   }

数组切片: x[start:end]

数组切片是对一个数组的连续部分的预览。 它们被写成 x[start:end]，其中 start 和 end 是表达式， 结果是uint256类型（或隐含的可转换类型）。分片的第一个元素是 x[start]， 最后一个元素是 x[end - 1]。

如果 start 大于 end，或者 end 大于数组的长度， 就会出现异常。

start 和 end 都是可选的： start 默认为 0， end 默认为数组的长度。

1
2
3

function get(uint[] calldata arr) public view returns (uint[] calldata){
      return arr[:6];
  }

数组元素：数组元素可以是任何类型，包括映射或结构体。 并适用于类型的一般限制，映射只能存储在 storage 数据位置,下面是一些特殊的数组。

bytes

bytes 类似于 bytes1[]， 但它在 calldata 中会被“紧打包”（译者注：将元素连续地存在一起，不会按每 32 字节一单元的方式来存放）。

您应该使用 bytes 而不是 bytes1[]，因为它更便宜， 因为在 memory 中使用 bytes1[] 会在元素之间增加31个填充字节。 一般来说，对于任意长度的原始字节数据使用 bytes，对于任意长度的字符串（UTF-8）数据使用 string。 如果您能将长度限制在一定的字节数，使用 bytes1 到 bytes32 中的一种值类型，因为它们更便宜。

函数: bytes.concat

bytes.concat 函数可以连接任意数量的 bytes 或 bytes1 ... bytes32 值。 该函数返回一个单一的 bytes memory 数组，其中包含没有填充的参数内容。 如果您想使用字符串参数或其他不能隐式转换为 bytes 的类型， 您需要先将它们转换为 bytes 或 bytes1 /…/ bytes32。

示例

1
2
3
4
5
6
7
8
9
10
11
12

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract C{
    bytes public Bytes = "abc";
    bytes public Bytes2 = "efg";
    string public s = "Storage";
    string public d = "Memory";
    bool public keccak =
    keccak256(abi.encodePacked(s)) == keccak256(abi.encodePacked(d));
    string public stringConcat = string.concat(s,d,string(Bytes),string(Bytes2));
    bytes public concatBytes = bytes.concat(Bytes,Bytes2,bytes(s),bytes(d));
}

string

string 与 bytes 相同，但不允许用长度或索引来访问。

Solidity没有字符串操作函数，但有第三方的字符串库。 可以用 keccak256(abi.encodePacked(s1)) == keccak256(abi.encodePacked(s2)) 来比较两个字符串的keccak256-hash，用 string.concat(s1, s2) 来连接两个字符串。

函数: string.concat

可以使用 string.concat 连接任意数量的 string 值。 该函数返回一个单一的 string memory 数组，其中包含没有填充的参数内容。 如果您想使用不能隐式转换为 string 的其他类型的参数，您需要先将它们转换为 string。

示例

1
2
3
4
5
6
7
8
9
10
11
12

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract C{
    bytes public Bytes = "abc";
    bytes public Bytes2 = "efg";
    string public s = "Storage";
    string public d = "Memory";
    bool public keccak =
    keccak256(abi.encodePacked(s)) == keccak256(abi.encodePacked(d));
    string public stringConcat = string.concat(s,d,string(Bytes),string(Bytes2));
    bytes public concatBytes = bytes.concat(Bytes,Bytes2,bytes(s),bytes(d));
}

结构体

Solidity 支持通过结构体定义新类型。

示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract Struct{
    struct user{
        string name;
        uint age;
        string email;
    }
    // function add(string memory name, uint age, string memory email)
    // public view returns (user memory){
    //     user memory newUser = user(name, age, email);
    //     return newUser;
    // }
    user user1;
    function add(string memory name, uint age, string memory email)
    external{
        user storage newUser = user1;
        newUser.name ="hello";
    }
}

结构体的赋值和访问

• 存储结构体：当结构体赋值给局部变量时，并不会复制数据，而是传递引用。
• 成员访问：可以直接访问结构体的成员，例如 campaigns[campaignID].amount = 0;。

映射类型

在映射中，人们可以通过键（Key）来查询对应的值（Value），比如：通过一个人的id来查询他的钱包地址。

声明映射的格式为mapping(_KeyType => _ValueType)，其中_KeyType和_ValueType分别是Key和Value的变量类型。例子：

映射的规则

规则1：映射的_KeyType只能选择Solidity内置的值类型，比如uint，address等，不能用自定义的结构体。而_ValueType可以使用自定义的类型。下面这个例子会报错，因为_KeyType使用了我们自定义的结构体：

规则2：映射的存储位置必须是storage，因此可以用于合约的状态变量，函数中的storage变量和library函数的参数（见例子）。不能用于public函数的参数或返回结果中，因为mapping记录的是一种关系 (key - value pair)。

规则3：如果映射声明为public，那么Solidity会自动给你创建一个getter函数，可以通过Key来查询对应的Value。

规则4：给映射新增的键值对的语法为_Var[_Key] = _Value，其中_Var是映射变量名，_Key和_Value对应新增的键值对。例子：

映射的原理

原理1: 映射不储存任何键（Key）的资讯，也没有length的资讯。

原理2: 对于映射使用keccak256(h(key) . slot)计算存取value的位置。https://github.com/WTFAcademy/WTF-Solidity-Internals/tree/master/tutorials/02_MappingStorage)

原理3: 因为Ethereum会定义所有未使用的空间为0，所以未赋值（Value）的键（Key）初始值都是各个type的默认值，如uint的默认值是0。

在Remix上验证 (以 Mapping.sol为例)

映射示例 1 部署

映射示例 3 key-value pair

运算符

在Solidity智能合约中，以下是一些常见运算符的简要说明和示例：

三元运算符

1

<条件表达式> ? <true条件表达式> : <false条件表达式>

允许根据条件表达式选择执行两个表达式之一。

1
2
3
4
5

uint public a = 10;
uint b = 20;
uint public x;
uint public max = a > b ? a : b;
uint public min = a < b ? a : b;

复合赋值运算符

-=，+=, *=， /=， %=， |=， &=， ^=， >=

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

function jian(uint y) public {
        // a = a - y;
        a -= y;
    }
    function add(uint y) public {
        // a = a + y;
        a += y;
    }
    function divide(uint y) public {
        // a = a / y;
        a /= y;
    }
    function multiply(uint y) public {
        // a = a * y;
        a *= y;
    }
    function test(uint y) public {
        // a %= y;  // a = 10 % 2 = 0
        // a |= y;  // a = a | y ;  10 | 2  1 0 1 0 | 0 0 1 0  = 1 0 1 0
        // a &= y; // a = a & y;  10 & 2  1 0 1 0 | 0 0 1 0  = 0 0 1 0
        // a ^= y;  // a = a ^ y  10 ^ 2  1 0 1 0 | 0 0 1 0 = 1 0 0 0
        // a <<= y;  // a = a << y  10 << 2  0 0 0 0 1 0 1 0  << 2 =  0 0 1 0 1 0 0 0 40
        a >>= y;  // a = a >> y  10 >> 2  0 0 0 0 1 0 1 0 >> 2   = 0 0 0 0 0 0 1 0
    }

用于简洁地对变量进行更新。

增量/减量运算符：

a++和a—

1
2
3

function add1() public {
       a++
   }

1
2
3

function divide1() public {
   x = a--;
  }

—a和++a

1
2
3

function add1() public {
        x = ++a;
    }

1
2
3

function divide1() public {
     x = --a;
 }

用于快速增加或减少变量的值。

删除运算符

在Solidity中是存在 delete 运算符的。使用 delete 可以将变量设置为其类型的默认值。对于简单类型，如 uint 或 int，默认值是 0；对于数组，delete 会使数组的所有元素被置为默认值；对于结构体，它将重置结构体中的所有成员变量为它们的默认值。
例如：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract test2{
    uint public x = 2;
    uint[]  array = [1,2,3,4];
    struct S { uint a; uint b;}
    S public s;
    function test() public returns(S memory){
        delete x;
        delete array[1];
        s.a = 5;
        s.b = 2;
        delete s;
        // delete s[0];
        return s;
    }
}

请注意，delete 对于动态数组只会将特定索引处的元素重置为默认值，并不会改变数组的长度。而对于静态数组，delete 将会重置整个数组为默认值。对于映射（mapping），delete 会使特定的键对应的值被移除。对于复杂类型的数组或映射，delete 不会递归删除内部元素，只会将它们设置为默认值。

运算符优先顺序：

运算符按照特定的优先级进行求值，例如：

• *、/、%（乘、除、取余）具有高于+、-（加、减）的优先级。
• &&（逻辑与）的优先级高于||（逻辑或）。
• 使用括号()可以改变默认的优先级。
  下面是一个运算符优先级的例子：

1
2
3
4
5
6
7
8
9
10
11

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract test3{
//     *、/、%（乘、除、取余）具有高于+、-（加、减）的优先级。
// &&（逻辑与）的优先级高于||（逻辑或）。
// 使用括号()可以改变默认的优先级。
    uint a = 2; uint b =3; uint c=4;
    // uint public result = a + b * c;
    // bool public result = true && false || false;
    uint public result = (a + b) * c;
}

基本类型之间的转换

隐式转换

在某些情况下，在赋值过程中，在向函数传递参数和应用运算符时， 编译器会自动应用隐式类型转换。一般来说，如果在语义上有意义， 并且不会丢失信息，那么值-类型之间的隐式转换是可能的。

uint8 => uint16, int128=>int256, int8 !=> uint256【!=-1】

1
2
3
4
5
6

uint8 y; uint16 z;
uint32 public x = y+z;
uint16 public j = y+z;
int128 public iy; int256 public iz;
int256 public ix = iy+iz;
int8 public io=-1;

显式转换

如果编译器不允许隐式转换，但您确信转换会成功， 有时可以进行显式类型转换。 这可能会导致意想不到的行为，并使您绕过编译器的一些安全特性， 所以一定要测试结果是否是您想要的和期望的!

int y=> uint(y)

1
2
3
4
5
6
7

// 1 0 0 0 0 0 0 1  确定源码 2进制符号 最高位1/0 负/正
// 1 1 1 1 1 1 1 0  计算反码 除最高位以外取反
// 1 1 1 1 1 1 1 1  补码，反码加一
// 128+127=255      十进制结果
uint256 public k = uint8(io);
uint8 public a = 255;
// uint8 public b = 256;

字面常数和基本类型之间的转换

整数类型

十进制和十六进制的数字字面常数可以隐含地转换为任何足够大的整数类型去表示它而不被截断。

1
2
3
4
5
6

//十进制转换
   uint8 public a = 255;
   // bytes4 b = bytes1(a); 可行
   // bytes4 b = a 不可行
   //十六进制常量
   bytes2 m = 0x1234;

固定大小的字节数组

十进制数字字面常数不能被隐含地转换为固定大小的字节数组。 十六进制数字字面常数是可以的，但只有当十六进制数字的数量正好符合字节类型的大小时才可以。 但是有一个例外，数值为0的十进制和十六进制数字字面常数都可以被转换为任何固定大小的字节类型

1
2
3
4

// bytes2 n = 0x12; 不行
  // bytes2 x = 0x12345; 不行
  bytes2 z = 0x0;
  bytes2 y = 0;

地址类型

正如在 地址字面量（Address Literals） 中所描述的那样，正确大小并通过校验测试的十六进制字是 address 类型。 其他字面常数不能隐含地转换为 address 类型。

1
2
3

// 地址类型
    address user = 0x5B38Da6a701c568545dCfcB03FcB875f56beddC4;
    // address a = address(0x0); 不行

总结:

• 隐式转换：只有在“范围扩大 + 不丢失信息”时才允许。
• 显式转换：允许开发者强制转换，但可能导致意外结果 → 必须验证。
• 字面量转换规则：
• 整数字面量可隐式转换（不超范围）。
• 十六进制字面量可用于定长字节数组（需精确字节数）。
• 地址必须是符合格式的十六进制字面量。

参考资料 :

Solidity — Solidity 0.8.24 文档

WTF Solidity课程

常量是内存中用于保存固定值的单元，在程序中常量的值不能发生改变。

在Go语言 中定义常量的方法如下：

例

1

const CAPITAL string = "Guangdong"

变量

变量是内存中命名的存储位置，与常量不同的是变量的值可以动态变化。与常量一 样，变量也有一个名字。

在Go语言中定义变量的方法如下：

例如，下面的代码定义了一个字符串变量str。

1

var str string = "Hello";

数据类型

1. 布尔型

Go语言的布尔型为bool，布尔型常量包括true和false。

例如，下面的代码定义了 一个布尔型变量existed。

1

var existed bool = false;

1. 数字类型Go语言的数字类型包括整型和浮点型。Go语言支持的整型数据类型如下图所示。

Go语言支持的浮点型数据类型如下图所示。

1. 派生类型Go语言的派生类型包括指针、结构体、枚举、数组、切片、集合、接口、通道、函数等。大多数派生类型都比较复杂，本小节只介绍其中比较简单的结构体类型和枚举类型。
   （1）结构体类型
   结构体是一种自定义的数据类型，即可以由一组不同的数据类型组合成一个新的数据类型。可以使用struct关键字来定义结构体类型，具体方法如下：
   type结构体类型struct {
   ​ 成员定义
   ​ 成员定义
   ​ ……
   ​ 成员定义
   }
   例如，下面的代码定义了一个Book结构体，其中包含Name（名称）、Author（作者）、Pagecount（页数）和Price（价格）等成员。
   1
   2
   3
   4
   5
   6
   type Book struct { Name string; Author string; Pagecount uint; Price uint; }
   定义结构体类型后，可以使用如下方法声明结构体变量。
   变量：= 结构体类型 {字段值1， 字段值2,…，字段值n}
   上面的代码在初始化结构体变量时按照其字段定义的顺序指定字段值，也可以按照 键值对的形式初始化结构体变量，方法如下：
   变量：= 结构体类型 {字段名1：字段值1， 字段名2：字段值2,…，字段名n：字段值n}
   初始化一个结构体时要指定每个成员的值。
   例如，初始化一个Book变量b的方法如 下：
   Book b = Book{“ 活着”, “余华”, 350, 90}
   可以使用b.Name来访问结构体的成员Name。
   运行结果
   

（2）枚举类型

枚举类型是一种有有限可选值的数据类型，每个可选值都对应一个int值。

在Go语 言中，可以使用const关键字来定义一个枚举类型，方法如下：

type <枚举类型名> int const (

<可选值1> <枚举类型名> = iota//值为0

<可选值2> //值为1

<可选值3> //值为2

<可选值4> //值为3

)

<可选值1>由iota初始化后，后面的可选值会自动递增。<可选值1>对应整型数0,< 可选值2>对应整型数1,<可选值3>对应整型数2，以此类推。

可以使用下面的方法引用枚举类型的可选值。

<枚举类型名>.<可选值n>

参考资料: Go语言Hyperledger区块链开发实战_(李晓黎)

1
2
3
4
5
6
7
8
9
10
11

package main

import "fmt"

func main()

{

fmt.Println("Hello World!")

 }

具体说明如下。

·程序使用package关键字定义了一个名为main的包。这说明当前程序是一个可执 行程序。

·程序使用import语句导入包fmt。fmt是Go语言的内置包，其中包含格式化I/O （Input/ Output，输入/输出）函数。

·func关键字用于定义函数。本例中定义了一个main()函数，这是项目的主函数， 也是执行程序的入口。

·调用fmt包中的Println()函数，在终端输出字符串“Hello World!”。

这是一个非常简单的Go语言程序，但是其中包含Go语言程序的必要元素，例如包、 函数和字符串等。本章后面会详细介绍这些概念。

参考资料: Go语言Hyperledger区块链开发实战_(李晓黎)

Go语言支持Windows、Linux、FreeBSD和macOS等多种操作系统。

下载官网

The Go Programming Language

这里只详细说一下windows怎么做，在windows中，下载完成之后的go默认的安装目录为C:\Program Files\Go【可以自行设置】，用户需要把C:\Program Files\Go\bin目录添加到环境变量PATH中【初次安装不需要，但也可能因人而异】，以便可以在任何目录下执行go命令。执行go version命令可以查看Go语言的版本信息，go env命令可以查看与Go语言相关的环境变量。

常用的与Go语言相关的环境变量如下。

·GOROOT：存储Go语言的安装目录，默认为C:\Program Files\Go。

·GOPATH：存储Go语言的项目目录，默认为C:\Users\Administrator\go。

参考资料: Go语言Hyperledger区块链开发实战_(李晓黎)

比特币 vs 以太坊：为什么需要智能合约？

比特币作为区块链技术的第一个成功应用，开创了去中心化数字货币的先河。它的核心功能是提供一种安全、透明且不可篡改的价值转移方式。然而，比特币的设计初衷是专注于支付和存储价值，其脚本语言（Script）虽然具有一定的可编程性，但功能较为有限，无法支持复杂的逻辑操作。
相比之下，以太坊在设计上引入了一个革命性的概念——智能合约。智能合约是一种运行在区块链上的程序代码，能够根据预设条件自动执行特定的操作。它使得以太坊不仅是一个去中心化的支付系统，更是一个通用的计算平台。通过智能合约，开发者可以构建各种去中心化应用（DApps），例如去中心化金融（DeFi）、非同质化代币（NFT）、去中心化自治组织（DAO）等。这种灵活性使以太坊成为区块链生态系统的核心支柱之一。
那么，为什么需要智能合约？智能合约的核心优势在于自动化执行和信任最小化。传统合约需要依赖第三方（如律师或仲裁机构）来确保执行，而智能合约通过代码直接定义规则并自动执行，无需中介参与。这不仅降低了交易成本，还提高了效率，同时减少了人为干预带来的风险。此外，智能合约的透明性和不可篡改性进一步增强了信任，使其在金融、供应链管理、身份认证等领域展现出巨大的潜力。

什么是Gas？什么是交易？

Gas

在以太坊网络中，Gas 是衡量执行智能合约或进行交易所需计算资源的单位。简单来说，Gas 是用户为使用以太坊网络支付的“燃料费”。每笔交易或智能合约的执行都需要消耗一定数量的 Gas，而 Gas 的价格由市场供需决定，通常以以太币（ETH）计价。
Gas 的存在有几个重要意义：

1. 防止滥用网络资源：通过收取 Gas 费用，以太坊可以防止恶意用户发起无限循环或占用大量计算资源的操作。
2. 激励矿工/验证者：Gas 费用作为奖励分配给矿工（在 PoW 机制下）或验证者（在 PoS 机制下），以保障网络的安全性和稳定性。
3. 动态调节网络负载：当网络拥堵时，用户可以通过提高 Gas 价格来优先处理自己的交易。

交易

在区块链语境中，交易是指任何改变区块链状态的操作。交易可以分为两类：

1. 普通转账交易：指从一个账户向另一个账户转移加密货币（如 ETH）。
2. 智能合约交互交易：指调用智能合约中的函数，可能涉及复杂的数据处理或状态更新。
   每笔交易都需要包含以下信息：

• 发送方地址
• 接收方地址（如果是普通转账）或智能合约地址（如果是合约交互）
• 转账金额（如果是普通转账）
• Gas 限制（Gas Limit）：用户愿意为该交易支付的最大 Gas 数量
• Gas 价格（Gas Price）：每单位 Gas 的价格
  如果交易执行所需的 Gas 超过了用户设置的 Gas 限制，交易将失败，但已消耗的 Gas 不会退还。

开发环境搭建（FISCO-BCOS, Remix IDE）

为了在区块链上开发和部署智能合约，我们需要搭建合适的开发环境。以下是两种常用的工具：FISCO-BCOS 和 Remix IDE。

FISCO-BCOS

FISCO-BCOS 是一个国产的区块链底层平台，专注于企业级应用场景。它支持联盟链模式，适合构建私有链或联盟链项目。以下是搭建 FISCO-BCOS 的基本步骤：

https://fisco-bcos-doc.readthedocs.io/zh-cn/latest/index.html

Remix IDE

Remix 是一个基于浏览器的集成开发环境（IDE），专为以太坊智能合约开发设计。它的界面友好，功能强大，非常适合初学者和快速原型开发。以下是使用 Remix 的基本流程：

1. 访问 Remix IDE：

• 打开浏览器，访问 Remix 官网。

1. 编写智能合约：

• 在 Remix 的“File Explorer”区域新建一个 .sol 文件，例如 MyContract.sol。
• 编写 Solidity 代码，例如：

1
2
3
4
5
6
7
8
9
10
11

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract MyContract {
    uint public value;
    function setValue(uint _value) public {
        value = _value;
    }
    function getValue() public view returns (uint) {
        return value;
    }
}

1. 编译合约：

• 切换到“Solidity Compiler”标签页，选择适当的编译器版本并点击“Compile”。

1. 部署合约：

• 切换到“Deploy & Run Transactions”标签页，选择 JavaScript VM（虚拟机）或其他环境（如 MetaMask）。
• 点击“Deploy”按钮将合约部署到测试网络。

1. 测试合约：

• 在“Deployed Contracts”区域，调用合约的函数（如 setValue 和 getValue）进行交互。

本周围绕农场相关系统的优化、功能扩展及上线展开工作，具体内容与成果如下：

（一）周一：后台界面优化工作

1. 本地存储数据安全优化：针对后台界面，移除了通过 storage 本地存储模拟操作数据的方式。此优化有效避免了操作数据在本地透明可见的问题，提升了数据传输与存储的安全性，降低了数据被篡改或泄露的风险。
2. 核心业务逻辑调整：重点调整了后台作物管理与日志操作的核心逻辑。优化后，系统能够精准匹配对应地块的种子信息，确保作物数据与地块信息的关联性；同时，日志信息也能与具体操作场景、地块及作物数据准确对应，提升了后台数据管理的准确性与可读性，为后续数据查询与分析奠定基础。

（二）周二：作物日志功能扩展

1. 操作频次管控实现：为规范作物日志记录，新增作物日志每日操作限制规则，设定每种操作每日最多记录两次。该规则有效避免了日志数据冗余，保证了日志信息的简洁性与有效性，同时也符合农场日常运营中对作物操作的合理频次需求。
2. 日志生命周期管理：完善作物日志的生命周期逻辑，实现 “收获后自动删除日志，后续重新操作时添加新日志” 的功能。此举确保了日志信息与作物生长周期的同步性，避免了过期日志对数据管理的干扰，提升了日志数据的时效性。
3. 弱网环境数据保障：采用幂等性设计实现作物日志记录功能，在弱网、网络不流畅等不稳定环境下，能够有效防止重复添加日志数据，同时确保操作数据的完整性与准确性，提升了系统在复杂网络环境下的稳定性与可靠性。

（三）周三：农场后台管理系统上线

1. 管家日志管理功能：上线的农场后台管理系统中，新增管家后台日志记录功能，管家可通过系统的 “作物管理” 模块与 “每周日志” 模块，实时记录、查看与管理作物相关的操作日志，便于管家全面掌握作物生长过程中的关键操作，提升管理效率。
2. 种子图鉴管理功能：系统支持管家通过 “种子管理” 模块，上传、编辑与管理种子图鉴信息，包括种子品种、生长周期、适宜环境等关键数据。该功能为管家提供了统一的种子信息管理平台，便于规范种子信息管理，同时也为后续作物种植规划提供数据支持。
3. 订单查询管理功能：上线 “订单管理” 模块，管家可通过该模块快速查询所有订单信息，包括订单编号、订单类型、下单时间、订单状态等详细内容，支持按不同条件筛选查询，提升了订单信息的查询效率，便于管家及时跟进订单进度，保障农场运营的顺畅性。

二、核心工作成果

本周聚焦农场相关系统完成三项关键工作：一是优化后台界面，移除 storage 本地存储模拟数据以强化安全，同时调整作物与日志逻辑，实现地块 - 种子 - 日志信息精准匹配；二是扩展作物日志功能，新增每日操作频次限制、收获后日志自动清理机制，并通过幂等设计解决弱网环境下数据重复问题；三是成功上线农场后台管理系统，为管家提供日志管理、种子图鉴上传、订单查询三大核心模块，满足日常管理需求。

三、关键价值与亮点

从安全性、实用性、稳定性三方面实现突破：安全层面，通过本地存储优化降低数据泄露风险，为系统数据安全奠定基础；实用层面，日志生命周期管理与后台系统功能模块，直接贴合农场运营场景，帮助管家提升数据管理与工作效率；稳定性层面，幂等设计的应用，有效应对复杂网络环境，保障操作数据的完整性，减少系统异常问题。

四、后续行动方向

后续将围绕 “优化体验、强化安全、拓展功能” 推进工作：优先收集管家使用反馈，迭代优化系统操作流程与功能漏洞；进一步完善数据安全体系，新增定期备份与恢复机制；结合农场实际需求调研新功能（如作物生长监控），同时持续监控系统性能，通过优化数据库、压缩资源等方式，确保系统长期稳定高效运行。

一、 每日开发详情

• 设计订单列表，可根据 order_type 动态展示信息。
• 实现按类型、状态等条件的筛选功能。
• 开发订单详情页，关联显示主表(t_order)与子表信息。
  ✅ 托管日志集成：在作物管理界面中，可查看关联的托管服务日志。
  ✅ 管家绑定：前端通过 store 中的用户ID查询并绑定 caretaker_user_id，管理作物。 |
  | 周三 | 前后端功能联调 | ✅ 日志查看：点击作物即可显示相关管家的操作日志。
  ✅ 订单管理：用户可查询并修改自己的订单信息。 |
  | 周四 | 功能优化与扩展 | ✅ 修复前端显示：优化购买服务页面，为播种功能做准备。
  ✅ 服务扩展：扩展下单服务，支持收获后生成配送订单的流程。
  ✅ 界面优化：对订单列表的“待收获”界面进行了视觉和体验优化。 |
  | 周五 | 交互功能实现 | ✅ 确认操作：实现前端确认操作（如浇水）的功能。
  ✅ 日志记录：为浇水等操作生成两种日志：
• 用户操作日志 (用户点击触发)
• 管家工作日志 (管家后台记录)
  ✅ 通知机制：管家可在后台管理系统中获取相关操作的通知和日志。 |
  | 周六 | 全链路测试与BUG修复 | ✅ 核心闭环验证：成功测试并修复逻辑BUG，确保从购买到收获下单的全流程畅通。
  ✅ 遗留问题定位：
• 问题一：手机端支付后可重复点击购买，需前端优化交互。
• 问题二：后台订单界面需集成第三方服务（如支付、物流），待确定方案。 |

二、 核心业务流程与逻辑 (本周重大进展)

1. 收获后处理逻辑（后端）：
   当用户发起收获并成功创建配送单后，系统自动执行以下操作，确保数据状态准确：

清空地块：将对应地块的作物状态重置为 empty。
2. 扣减权益：
对于次数型权益：将 uses_left (剩余次数) 减1。若次数用尽，则将权益状态置为 consumed。
3. 对于时长型权益：不扣减次数，仅检查有效期。
4. 更新权益状态：重新计算该地块的 owned 字段。只要仍有有效的active权益（次数未用完或未过期），owned 即为 true，否则为 false。
5. 前端支付流程优化（已解决）：
修复了 purchaseServicePackage 函数中 await 与 success 回调混用导致的逻辑问题。

解决方案：重写该函数，采用纯 async/await 方式调用支付接口。支付成功后，立即调用后端接口刷新地块数据，并提交一个 mutation 来本地更新状态，确保UI显示及时、准确。

三、 待解决的问题与下周计划

下周计划：

• 解决遗留问题：优先修复移动端支付交互BUG，并启动第三方服务对接的调研与开发。
• 功能增强：基于已打通的闭环，考虑添加更多作物管理操作（如施肥、除虫）、优化日志系统、设计更完善的管家通知中心。
• 测试与部署：进行更全面的测试，准备将新功能部署至测试或生产环境。

四、 本周工作回顾：核心业务闭环全面打通

本周的核心工作是推动农场项目的完整业务流程实现与后台管理系统强化，并成功完成了端到端的测试验证。

1. 后端服务建设：完成了下单服务与后台托管服务的开发，实现了订单的接收、处理、存储，以及管家的任务分配与权限管理。
2. 后台管理功能增强：开发了功能完善的订单管理页面（列表、筛选、详情）、托管服务日志记录模块，并实现了作物与管家的绑定管理。
3. 核心业务闭环验证：成功打通了“用户购买服务 -> 播种 -> 进行浇水等管理操作 -> 自动生成日志 -> 收获并创建配送单 -> 地块状态重置”的完整业务流程，标志着项目最核心的功能链路已全部跑通。
4. 前端体验优化：修复了购买服务页面的显示问题，优化了订单界面，并重写了支付逻辑，确保了交互的准确性和数据的一致性。

五**、 问题与反思：技术方案与细节处理需持续打磨**

在开发过程中，也遇到并识别了一些亟待解决的问题，主要集中在交互细节和技术方案选型上。

1. 移动端交互细节问题：手机端支付成功后，按钮状态未能及时重置，导致用户可重复点击，暴露了前端对连续请求控制的不足。这需要通过添加加载状态和按钮禁用机制来优化。
2. 外部集成技术方案待定：后台系统需要接入支付、物流等第三方服务，但目前尚未确定具体的技术选型和对接方案，这是下一步需要重点调研和决策的点。
3. 逻辑严谨性：在解决“收获后清空地块”等复杂业务逻辑时，意识到必须通过精准的后端逻辑（如扣减权益、状态更新）来保证数据一致性，而非依赖前端。

六、 下周计划：解决遗留问题，推进系统集成与优化

基于本周的进展和问题，下周的工作将围绕以下重点展开：

1. 优先解决遗留问题：
   修复移动端支付交互BUG，增加防重复提交机制。
2. 启动对第三方服务（如支付、物流API）的调研，并形成初步的集成方案。
3. 功能增强与优化：
   在现有闭环基础上，规划并开发更多的作物管理操作（如施肥、除虫）。
4. 优化日志系统和管家通知中心，提升用户体验和管理效率。
5. 测试与部署准备：
   对已打通的全流程进行更全面的测试，准备将稳定版本部署至测试环境。

完成工作：

• 实现托管服务操作流程：点击托管→选择种植物→确认收获→判断收获方式。
• 搭建基础农场前端界面，完成用户交互逻辑。

遇到的问题：

• 收获方式判断逻辑需与后端土地状态同步（未实时更新）。

解决方式：

• 添加前端定时查询地块状态，确保数据一致性。

周二：订单生成与支付界面优化

完成工作：

• 对接托管服务订单接口（/orders/service），生成订单并关联用户与地块数据。
• 优化支付界面样式，使其更简洁清晰，支持后续扩展托管服务类型。
• 实现土地及托管服务数据存储，支持详细查询。

遇到的问题：

• 支付界面在不同设备上显示错位（移动端适配问题）。

解决方式：

• 使用响应式布局（CSS Flexbox+Media Query）快速修复。

周三：扩展购买与播种功能

完成工作：

• 扩展托管服务购买功能（接口：/farm/service/package/purchase）。
• 实现种子播种功能（接口：/farm/plant）并关联地块数据（接口：/farm/plots）。
• 订单查询与支付状态联动（支付成功自动更新订单状态）。

遇到的问题：

• 播种请求超时（地块数据量增大导致查询缓慢）。

解决方式：

• 为/farm/plots接口添加缓存机制（Redis缓存地块信息）。

周四：后台管理系统开发

完成工作：

• 实现后台托管服务管理（增删改查）。
• 开发作物管理模块（支持作物信息维护）。
• 搭建每周日志记录功能（支持日志添加与查询）。
• 完成种子管理基础功能（CRUD操作）。

遇到的问题：

• 管家管理模块需对接若依权限系统，但账户体系不兼容。

解决方式：

• 暂独立开发管家管理模块，预留若依系统对接接口。

周五：后台功能完善与权限隔离

完成工作：

• 完成托管服务、作物管理、每周日志、种子管理的完整增删改查功能。
• 优化后台数据查询效率（添加数据库索引）。
• 管家管理模块独立运行（暂未关联若依登录）。

遇到的问题：

• 若依系统权限接口文档缺失，无法直接对接。

解决方式：

• 优先保证其他后台功能上线，管家管理采用若依账号过渡。

本周总结

1. 独立完成内容

• 前端农场服务全流程（托管→支付→播种→收获）。
• 订单与支付系统集成（微信支付+订单状态管理）。
• 后台管理核心功能（作物、日志、种子、托管服务管理）。

2. 主要挑战

• 支付合规性：订单号长度限制（32位）、HTTPS证书配置。
• 系统兼容性：管家模块与若依权限系统账户体系不匹配。
• 性能问题：地块数据量增大导致查询缓慢。

3. 成长与改进

• 第三方集成经验：支付接口必须严格遵循字段规范（如订单号长度）。
• 解耦设计：模块化开发（如管家管理独立）降低系统耦合风险。
• 性能优化：引入缓存与数据库索引应对数据增长。

4. 后续计划

• 补全若依系统对接文档，完成管家权限集成。
• 统一接口响应格式，编写后端API文档。
• 增加农场操作（播种、收获）的事务回滚机制。

总结：本周成功交付农场系统核心功能，但支付与权限集成暴露了预研不足的问题。后续类似项目需提前验证第三方接口（支付、登录）的合规性；

一、 每日工作记录

• POST /farm/plant： 种植接口
• POST /farm/init： 初始化用户田地
• POST /farm/listByUser： 获取用户田地信息 |
  | 周五 | 联调与架构复盘 | ✅ 成功完成前端与农场服务的联调，可获取并展示用户种植数据。
  ✅ 架构决策：确定使用混合云开发方案（自建MySQL + 云服务），兼顾了数据灵活性与开发效率。 |

二、 本周最大的挑战与解决方案

• 挑战： 技术选型在数据库扩展性与开发维护效率之间的权衡。纯微信云开发无法满足复杂的MySQL业务需求，而完全自建服务器运维成本较高。
• 解决方案： 采用混合云架构。
  核心业务数据（用户、订单、农场）：使用自建云服务器上的MySQL数据库，保证了对数据的完全控制和复杂查询能力。
• 静态资源/轻量功能：后续可考虑使用云开发平台的服务，提升开发速度与稳定性。

三、 本周工作带来的成长

1. 全链路能力提升： 从最基础的HTTPS配置，到复杂的支付业务、数据库设计，再到后端服务开发，独立打通了核心功能的全链路，对前后端协同开发的理解更加深刻。
2. 技术方案设计能力： 不再局限于实现功能，开始从架构角度思考问题（如混合云选型），学会了在多种技术方案中权衡利弊，选择最适合当前业务阶段的方案。
3. 文档驱动开发： 通过编写设计文档来理清逻辑，再着手编码，有效减少了开发过程中的反复和错误，提升了开发效率和质量。

四、 反思与未来优化

• 本周不足： 最初的方案设计对云原生和混合架构的考量不够深入，导致中途需要调整技术路线，产生了一定的学习成本。
• 未来优化：
  架构设计：在项目初期，应更系统地评估各种技术方案（自建、纯云、混合云）的优缺点，制作详细的对比表格，避免后期切换。
• 可维护性：虽然混合方案稳定，但未来可以考虑使用Docker容器化来部署MySQL和应用，提升环境一致性和迁移效率。
• 功能完善：下一步需补全退款流程，并开始构建基于农场数据的商城购买与订单生成功能，最终完成商业闭环。

关键亮点说明：

1. 技术选型：

选择 若依框架 → 节省60%基础模块开发时间
2. 放弃纯云开发 → 因 MySQL业务兼容性 不足
3. 架构突破：
graph LR A[微信小程序] --> B{云存储} A --> C[自建服务器] B --> D[图片/文件] C --> E[MySQL业务库]
混合架构价值：静态资源云化减压，核心数据自主可控

一、独立完成事项 & 挑战与成长

• 技术选型（若依框架）
• 功能模块规划文档 | • 平衡开发效率与后期扩展性 | • 选择 开源后台框架若依（集成权限管理/代码生成） | ✅ 掌握 快速搭建企业级后台 的方法论 |
  | 2. 核心模块开发
• 用户管理（增删改查）
• 订单/土地管理功能 | • 数据库设计需兼容农场业务逻辑
  • 字段关联性复杂 | • 先画 ER图梳理数据关系
  • 用若依代码生成器快速实现基础CRUD | ✅ 提升 业务模型抽象能力
  ✅ 熟练 框架工具提效技巧 |
  | 3. 技术方案优化
• 尝试微信云开发
• 图片上传BUG修复 | • 云开发与传统MySQL不兼容
  • 图片路径存储异常 | • 改用 混合云架构：
• 核心业务用云服务器+MySQL
• 图片/文件用云存储 | ✅ 理解 混合云方案设计思维
  ✅ 学会 根据场景灵活选型 |

二、本周工作思考

1. 「快 vs 稳」的博弈：

若依框架虽加速开发，但过度依赖其生成代码可能导致技术债积累（如订单扩展字段需手动调整），下次需预留20%自定义空间。
2. 云服务的双刃剑：

微信云开发适合轻量应用，但数据库生态封闭（不支持MySQL）成为硬伤，混合架构虽解燃眉之急，也带来运维复杂度。

三、若重来我会如何做？

1. 技术选型更严谨：

制作 方案对比表（如下），避免试错成本：
| 方案 | 扩展性 | 维护成本 | 适合场景 |
| —————— | ——— | ———— | ——————— |
| 自建MySQL | ★★★★ | 中 | 复杂业务 |
| 纯微信云开发 | ★★ | 低 | 轻量工具类应用 |
| 混合云 | ★★★ | 中高 | 中庸型项目 |
2. 非核心功能（如图片上传）彻底云化，直接用云开发SDK。
3. 建立原型验证机制：

重要模块（如订单状态机）先写 伪代码流程图 与产品确认，避免返工。

总结：本周深刻体会架构选型需考量 业务生命周期（短期效率 vs 长期扩展）。未来将坚持 “设计-原型-开发”三步走，让技术真正服务业务增长。

• 完成租地功能：设计租赁信息表，JWT鉴权后创建租赁记录。
• 注意点： 补充了状态字段设计。

周二：

• 构建订单系统：创建订单主表及详情表，实现：
  JWT用户订单查询
• 多状态分类（待支付/待发货等）
• PageHelper分页（>10自动分页，加载页面缓存进度）

周三：

• 订单详情增强：调用土地接口展示租赁地块信息。
• 前端隐患：this.orderInfo.items[0] 强耦合数据绑定。

周四：

• 订单状态管理：实现增删改查及状态流转（如取消订单同步释放土地）。
• 优化： 采用状态模式替代if-else链。

周五：

• 支付功能受阻：
  致命问题： 后端未配置HTTPS（微信支付强制要求）
• 设计缺陷： 订单号长度不符支付接口规范（20位≠32位）
• 转向： 启动手机号验证方案研究。

周六：

• 微信验证困局：
  手机号快速验证失败（需企业认证）
• getUserProfile仅获取基础信息（头像/昵称）
• 开放数据解密流程复杂且无进展

核心卡点：

1. 支付环节： HTTPS缺失 + 订单号设计缺陷
2. 微信生态： 政策收紧导致手机号获取路径封死

一、独立完成 & 挑战 & 成长

二、本周工作思考

1. 做得好的
   基础功能闭环：租地→订单→状态流转全链路跑通
2. 快速响应问题：发现订单号缺陷应该立即重构
3. 待改进的
   致命疏忽：支付未提前验证HTTPS/字段规则 → 导致整块功能返工
4. 过度乐观：低估微信政策限制（开发者权限）
5. 核心认知
   “能开发” ≠ “能上线”
   第三方依赖的合规性（HTTPS/政策）比代码更重要

三、未来同样机会的做法

1. 预研四象限（首日必做）
   1
   2
   3
   4
   [技术] [政策] [环境] [兼容性] │ │ │ │ ├─HTTPS? ├─微信文档? ├─测试账号? ├─字段长度? └─SDK兼容 └─权限范围 └─域名备案 └─数据格式
2. 设计两原则

字段设计：订单号/金额等支付相关字段，直接对齐微信要求（32位/UUID）
3. 解耦开发：支付模块用模拟运行，便于替换（例：HTTPS未就绪时模拟支付）
4. 政策应对

项目避免强依赖微信敏感接口（如手机号）

总结一句话：
下次先花2小时跑通支付Demo+政策验证，再动手写业务代码。
功能开发速度 ≠ 交付速度，预研省下的就是返工浪费的。

本周主要进展：

1. 项目启动与基础搭建 (周一)：

用开发工具创建了小程序项目框架。
2. 首页： 实现了图片热区点击跳转（用绝对定位精确定位点击区域，uni.switchTab跳转底部菜单页）。
3. 公告栏： 暂时留空。
4. 我的农场： 开始设计核心玩法（比如种植收获逻辑）。
5. 个人中心： 画好了页面布局。
6. 图片上传到图床，减小小程序安装包体积。
7. 界面优化与农场互动 (周二)：

首页： 用媒体查询让页面在不同尺寸手机上都好看（响应式布局）。
8. 我的农场： 用Grid网格布局做了9块整齐的地块。点击地块能弹出操作图片（比如选择种子）。
9. 个人中心： 本想做微信一键登录（获取手机号），但个人小程序权限不够。改用方案：用户授权获取微信头像和昵称绑定账号，登录成功后服务器返回一个token（身份令牌）存起来，代表用户已登录。
10. 新增功能模块 (周三)：

首页： 加了“马克农场”入口，点击后跳转新页面（用uni.navigateTo页面跳转）。
11. 个人中心： 增加了“设置”页面，可以修改个人信息。
12. 核心登录功能实现 (周四)：

个人中心：
实现了完整的微信登录流程：
小程序获取临时登录凭证code。
13. 把code发给我的后台服务器。
14. 后台用code向微信服务器换取用户的唯一标识(openid)等信息。
15. 后台查数据库：如果是新用户，就创建账号；老用户则读取信息。
16. 后台生成token，连同用户信息一起返回给小程序。
17. 小程序把token和用户信息存起来（storage），后续操作代表该用户。

用户信息保护与更新 (周五)：

• 完善登录后的安全措施：采用JWT令牌进行鉴权（验证身份）。
  为什么选JWT？ 主要因为它不需要Cookie，避免了跨域(CORS)问题，更方便不同服务器间协作。而且服务器不用存储用户登录状态（无状态），减轻负担。
• 怎么用？ 用户登录后拿到JWT token（就是周四的那个token）。当用户想修改头像昵称等需要登录的操作时，小程序在请求头里带上这个token（格式：Authorization: Bearer ）。后台收到请求后，先验证token是否有效且合法，验证通过了才允许修改用户信息。

简单来说，这周： 搭好了小程序的基础架子，重点实现了用户登录注册流程（包括微信授权、后台验证、生成令牌JWT），完成了个人中心的主要功能（信息展示、设置、头像昵称修改），并开始为订单系统做跳转准备。技术上解决了图片优化、布局适配、登录授权、身份验证（JWT）等关键点。

以下是对本周工作的结构化复盘总结，结合实践与成长思考：

一、独立完成事项 & 挑战与成长

• 微信登录+JWT鉴权
• 头像/昵称修改功能 | • 个人小程序无法直接获取手机号
  • JWT无状态鉴权首次实战 | • 改用 Code→OpenID→Token 替代方案
  • 研读JWT机制，设计 Bearer Token 请求头鉴权逻辑 | ✅ 掌握受限条件下的灵活架构能力
  ✅ 理解无状态认证的设计优势与风险 |
  | 2. 农场交互核心模块
• Grid九宫格布局
• 地块点击弹窗交互 | • 动态弹窗与地块操作状态联动
  • 多端样式适配 | • 用 CSS变量+媒体查询 控制响应式
  • 事件委托 统一管理地块点击逻辑 | ✅ 强化 复杂交互前端设计能力
  ✅ 提升 CSS3实战应用水平 |
  | 3. 项目基建优化
• 图床节省包体积
• 路由传参统一管理 | • 图标库兼容性问题
  • 路由跳转类型混乱 | • 源码调试+强制样式覆盖 解决依赖冲突
  • 封装 路由工具函数 统一处理?type=参数 | ✅ 学会 第三方库问题排查技巧
  ✅ 养成 提前封装工具类 的习惯 |

二、本周工作思考

1. 技术决策的价值：

选择JWT不仅解决了跨域问题，更让我意识到技术选型需服务业务场景——个人小程序无法用企业级登录方案时，用Token机制快速搭建安全认证体系是最优解。

2. 限制催生创新：

微信API权限限制反而推动设计出更通用的 「Code+OpenID+DB」用户绑定流程，未来扩展手机号/邮箱登录只需复用该流程。

3. 技术债预警：

临时解决CSS兼容性的“hack手段”需在迭代中重构，开发效率与代码质量必须动态平衡。

三、若重来我会如何做？

1. 前置设计更彻底：

用流程图预先规划登录/鉴权全链路（避免周四返工）
订单系统数据库提前预留扩展字段（如order_type应对跳转传参）

2. 技术方案分层验证：

关键模块（如JWT）先写技术原型Demo再集成
第三方库（uView）提前做兼容性测试矩阵

3. 自动化提效：

用CI/CD工具自动压缩图片上传图床
编写路由配置生成脚本避免手写跳转参数

总结：未来需更注重前瞻性设计与可持续架构，让代码既能跑得快，更能跑得远。

本周开发纪实：

1. 周一： 复盘上周工作，为本周冲刺蓄力。
2. 周二： 承接新需求：
   记住手机号： 提升用户体验。
3. 自定义弹窗： 实现灵活交互。
4. 价格需求： 核心业务逻辑。
5. 技术选型： 确定使用 HttpSession 存储 手机号:验证码 键值对，作为临时认证方案。
6. 周三： 功能实现日
   完成“记住手机号” ✅
7. 集成验证码登录 ✅ (注意点： 接口参数类型需严格匹配，Session ID 不一致会导致校验失败 - 已解决)
8. 实现协议勾选及自定义弹窗 ✅
9. 兼容性问题： 确认微信浏览器不支持 datalist 元素。 (已找到替代方案-采用div来自定义下拉框✅)
10. 周四： 优化与设计
    验证码生命周期优化： 将清除逻辑从固定5分钟 (setInterval)，升级为 登录成功即销毁 或 5分钟到期销毁，更贴合实际场景。
11. 数据库设计： 新增 订单表 (order)。
    关键设计：通过 spot_id 外键关联车位表。
12. 决策说明：未直接复用车位表 user_id 字段 (因车位归属逻辑与订单用户逻辑存在差异)。
13. 周五： 数据库深化
    完善 订单表 结构，清晰记录交易信息。
14. 设计 优惠规则表 (discount_rule)，定义车位关联的折扣类型与规则。 (终于给优惠上了“户口本”)
15. 周六： 逻辑实现 & 性能飞跃
    完成订单金额计算引擎，支持匹配优惠规则。
16. 接口性能重大优化：
    问题： 原有设计需两个接口拉取 全量用户车位数据，效率低下。
17. 方案： 重构为单一接口，精准查询 当前用户订单信息。
18. 成果： 响应速度显著提升，数据库压力大幅降低。 ( 成功给臃肿接口“瘦身” )

本周总结与反思：

1. 主要成就与挑战：

独立完成： 成功独立完成了车位及订单模块的后端接口开发、前端订单页面设计以及相关数据库设计。
2. 关键挑战： 如何在后端安全、有效地存储和验证用户专属的短信验证码，避免多用户共用同一验证码的风险。
3. 解决方案： 采用基于 HttpSession 的存储方案：
Key: 用户手机号
4. Value: 对应的验证码
5. 生命周期管理：用户成功登录后或 Session 超时（设置 5 分钟）自动销毁。
6. 成长点： 深入理解了 HttpSession 机制在后端数据临时存储中的应用。
7. 反思与改进点：

需求理解： 未来开发前，应更深入地与客户/产品沟通需求细节，以便更好地支持后续扩展性开发。
8. 数据库设计： 反思当前设计是否足够精细？例如 user 表可考虑增加 user_type、created_at、last_login_at 等字段增强功能性和可追溯性。
9. 设计文档： 意识到个人设计文档的详细度有待提高，需加强文档规范。
10. 未来优化方向：

沟通： 加强沟通，确保需求理解透彻，及时同步进展。
11. 数据库：
精细化核心表结构（如扩展 user 表字段）。
12. 建立更清晰的表关系。
13. 后端架构：
进行更清晰的分层设计（Controller / Service / Repository / Entity）。
14. 将车位管理、用户收藏等模块进行逻辑拆分，提高可维护性。
15. 前端：
加强浏览器兼容性测试（如已发现的微信 datalist 问题）。
16. 持续进行界面加载速度优化。
17. 目标： 通过以上改进，全面提升开发效率、代码质量和系统健壮性，促进个人技术能力的成长。

Day 1: HTML星辰大海，打包是个误会？
产品经理的原型图甩过来，先设计好文档没问题了再开干！祭出神器 Cursor + Claude-3-Connect，AI 辅助下吭哧吭哧撸完一堆纯 HTML 页面。AI 老哥贴心提示：“亲，打包上传哦~”。我信了！一头扎进打包工具的坑里折腾半天，汗流浃背。结果？发现特么的纯 HTML 直接扔服务器就能跑！ 打包？打包了个寂寞！今日教训：AI 的话，也得结合上下文判断啊… (╯‵□′)╯︵┻━┻

Day 2: SpringBoot 从零开始，CSDN 付费墙刺客！
今日任务：搞后端 API 录入。第一次正经从零搭 SpringBoot 项目。IDEA 社区版 2023 有点坑，创建方式藏得深。CSDN 搜教程，好家伙，第一步就让装个插件，装完重启直接弹登录+付费订阅！真·知识付费刺客！果断弃坑。翻到良心文章指路：https://start.spring.io，官方生成器真香！唯一小插曲：我 JDK 11 的“老环境”，伺候不了 SpringBoot 3 这位“新贵”，手动把版本和相关依赖降级到 2.x，世界终于清净。结论：CSDN 水文害人，官方文档/工具永流传！

Day 3: 宝塔端口玄学 & “数字小孩”落户口！
任务：把后端 API 部署上云服务器（宝塔面板）。一顿操作猛如虎：端口放行√，配置√。测试？死活连不上！ CSDN 又跳出来“指点”：搞个随机域名数据库？一看还得付费固定域名？我信你个鬼！焦头烂额之际，猛然想起腾讯云还有个安全组！ 火速添上端口规则，瞬间畅通！啊，这熟悉的安全感… (长舒一口气)

• 技术小悟： 跨域问题，不一定非搬 Nginx 大神。后端配个全局 CORS，指定好前端地址，也能愉快玩耍！省事！
• 短信验证码插曲： 折腾半天接好了，但备案没过的号能发成功吗？心里有点虚，先当它行吧！

🌟 今日高光时刻 🌟
今年我们团队的心血——“医疗健康问诊系统”，喜提国家版权局颁发的《计算机软件著作权登记证书》！ 正式拥有了“数字小孩”的户口本！🎉

感谢并肩作战的伙伴，
感谢每个改bug到天亮的自己。
——【医疗健康问诊系统】软著𝐆𝐞𝐭，未来可期！

Day 4: 切图仔の挣扎 vs 后端の从容（伪）
实现一个“点击录入所有数据”的功能。纯 HTML + Vue 的组合，对我这个后端半吊子来说，操作 DOM 像在绣花… 切图仔，属实不易！ 顺带搞了车位收藏功能，数据库表设计修修补补好几回，勉强上线。结论：前端水太深，后端（的CRUD）才是俺的舒适区（暂时）！

Day 5: 数据库改改改，AI又救我狗命！
搞车位收藏和抢购的多表查询。是的，我又双叒改数据库了！ 最初设计图样图森破：想着一个车位记录，既能标记收藏又能记录谁买了，还绑 UserID。结果，“车位必须空闲”的规则和用户操作直接打架！卡壳半天，求助 AI 老哥，一语点醒：这设计有坑！火速重构，把状态、归属理清楚，功能终于跑通。教训：数据库设计，脑子得提前多绕几圈，少走弯路！

周记结尾：
第一周，在疯狂踩坑、暴躁搜索、偶尔顿悟和一次巨大惊喜（软著！）中飞逝。从打包误会到安全组玄学，从被 CSDN 付费墙背刺到 AI 救场，从切图痛苦到改库狂魔… 真实又酸爽！ 见识了工具的便利与坑爹，体会了团队的温暖（和一起加班）。代码世界的大门刚推开一条缝，路还长，坑还多，但看着“数字小孩”上了户口，值了！下周，继续升级打怪！

Main.sol

以下是智能合约代码的逐段解析，按功能模块分类说明：

1. 患者信息管理

结构体定义

1
2
3
4
5
6
7

struct Sick {
    address accountAddress; // 患者钱包地址
    string name;            // 姓名
    string sex;             // 性别
    uint256 age;            // 年龄
    uint256 id;             // 身份证号(主键)
}

数据存储

1
2

mapping(uint256 => Sick) public sicks;  // 身份证号→患者信息的映射
uint256[] public sickIds;               // 所有患者身份证号列表

核心功能

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

// 创建患者档案 (需校验参数有效性)
function createSick(...) public {
    // 参数校验...
    sicks[identityNumber] = Sick(...);  // 存储信息
    sickIds.push(identityNumber);       // 记录ID
    emit SickCreated(...);              // 触发事件
}

// 按身份证查询患者
function getSickByIdentityNumber(...) public view returns (...) {
    require(sick.accountAddress != address(0)); // 校验存在性
    return (sick.accountAddress, ...);
}

// 按钱包地址查询患者
function getSickByAccountAddress(...) public view returns (...) {
    uint256 sickID = findSickIDByAccountAddress(accountAddr); // 内部遍历查找
    return (sick.name, ...);
}

// 辅助函数：地址→ID映射
function findSickIDByAccountAddress(...) internal view returns (...) {
    for (uint256 i = 0; i < sickIds.length; i++) {
        if (sicks[sickID].accountAddress == accountAddr) return sickID;
    }
    return 0;
}

// 检查患者是否存在
function isSickExist(uint256 sickID) public view returns (bool) {
    return sicks[sickID].accountAddress != address(0);
}

// 获取所有患者ID列表
function getSicksList() public view returns (uint256[] memory) {
    return sickIds;
}

2. 预约挂号系统

结构体定义

1
2
3
4

struct Appointment {
    string hospitalName; // 医院名称
    string department;   // 科室名称
}

数据存储

1

mapping(uint256 => Appointment) public sickAppointment; // 患者ID→预约信息

核心功能

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

// 创建预约
function createAppointment(...) public {
    require(isSickExist(sickID));          // 患者必须存在
    sickAppointment[sickID] = Appointment(...); // 存储预约
    emit AppointmentCreated(...);           // 触发事件
}

// 查询预约
function getSickAppointment(...) public view returns (...) {
    require(bytes(appointment.hospitalName).length > 0); // 校验存在性
    return (appointment.hospitalName, ...);
}

// 删除预约
function deleteSickAppointment(uint256 sickID) public {
    delete sickAppointment[sickID];  // 清除预约记录
}

3. 电子病历管理

结构体定义

1
2
3
4
5
6
7
8
9
10

struct MedicalRecord {
    uint256 sickID;               // 患者ID
    string hospitalName;          // 医院
    string department;            // 科室
    string doctorName;            // 医生姓名
    string registrationInfo;      // 挂号信息
    string pastMedicalHistory;    // 既往病史
    string currentMedicalHistory; // 现病史
    string isFilled;              // 是否完成("Yes"/"No")
}

数据存储

1

mapping(uint256 => MedicalRecord) public sickMedicalRecords; // 患者ID→病历

核心功能

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

// 创建空白病历
function createMedicalRecord(...) public {
    sickMedicalRecords[sickID] = MedicalRecord(...);
    emit MedicalRecordCreated(...);
}

// 授权医生访问病历
function authorizeDoctor(...) public {
    if (病历不存在) createMedicalRecord(...); // 自动创建空病历
    sickMedicalRecords[sickID].doctorName = doctorName; // 设置医生
}

// 更新病历内容
function updateMedicalRecord(...) public {
    medicalRecord.hospitalName = hospitalName;
    medicalRecord.pastMedicalHistory = pastMedicalHistory; // 更新病史等
    emit MedicalRecordUpdated(...);
}

// 查询完整病历
function getMedicalRecordByIdentityNumber(...) public view returns (...) {
    return (medicalRecord.hospitalName, ...); // 返回所有病历字段
}

// 查询特定科室的既往病史
function getPastMedicalHistory(...) public view returns (...) {
    require(keccak256(科室)==keccak256(目标科室)); // 严格科室匹配
    return medicalRecord.pastMedicalHistory;
}

// 标记病历完成状态
function endMedicalConsultation(...) public {
    medicalRecord.isFilled = mrtype; // 设置"Yes"/"No"
}

// 检查病历是否完成
function isMedicalRecordFilled(...) public view returns (bool) {
    return keccak256(medicalRecord.isFilled) == keccak256("Yes");
}

该合约完整实现了患者档案管理、挂号预约、电子病历三大核心功能，构建了医疗数据上链的基础框架。