Flutter StatefulWidget中函数定义在Widget State上下的差异

类内部成员的书写顺序完全不会带来任何功能、性能、运行逻辑层面的差异。
Dart语言对类成员的解析不依赖代码书写的前后位置，只要方法、字段是定义在同一个类的作用域内，不管你把它写在类的靠前位置还是靠后位置，编译后的产物完全一致，运行时没有任何区别。你和同事的写法差异纯粹是代码风格偏好问题，不存在对错。

只有当方法的定义位置不在同一个作用域时才会产生实际影响，和上下顺序无关：

• 如果方法是写在State子类的大括号内部：不管是写在build方法上方、字段声明后面，还是写在build方法下方、类的最末尾，行为完全一致
• 如果方法被写在了State类的外部（比如写在StatefulWidget子类里、写在全局作用域）：才会出现作用域问题——这类方法无法直接访问State的私有成员、无法直接调用setState，如果要获取上下文还需要手动传参，容易出现生命周期不匹配的bug。

你贴出的示例代码里有一个比方法排序优先级高得多的隐患：当前showModal方法是定义在StatefulWidget的子类MasterAppointmentCreatePage中，而非对应的State子类里。
StatefulWidget本身是不可变的配置类，不适合持有这类和BuildContext、UI弹窗交互相关的业务逻辑：

• 方法中需要手动传入context参数，很容易出现传入的context和当前Widget生命周期不匹配的问题
• 后续如果弹窗内容需要依赖组件状态，无法直接访问State中的变量，维护成本会变高
  建议把这类UI交互相关的方法挪到对应的State类中实现。

Dart和Flutter官方没有强制要求类内部方法的排序规则，只要团队内部统一规范即可，常见的排序逻辑有两种：

• 构造函数 > 字段声明 > 生命周期方法（initState/didChangeDependencies/dispose等）> 自定义业务方法 > build方法
• 构造函数 > 字段声明 > 生命周期方法 > build方法 > 自定义业务方法
  第二种写法也是很多开发者的习惯，把build方法放在靠前位置，能更快定位UI构建逻辑，自定义方法全部放在build下方，阅读体验更流畅。

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