Flutter：setState()内代码位置是否影响StatefulWidget重建？

嘿，这个问题问到点子上了！不少刚摸Flutter的朋友都会纠结：到底把状态修改的代码塞去setState()的回调里，还是放在外面再调用空的setState，这俩到底有没有区别？咱先把你给出的两种写法补全，再好好唠唠。

先看完整的两种写法：

写法一（官方推荐） #

class _ShoppingListState extends State<ShoppingList> {
  Set<Product> _shoppingCart = new Set<Product>();

  void _handleCartChanged(Product product, bool inCart) {
    setState(() {
      if (inCart)
        _shoppingCart.add(product);
      else
        _shoppingCart.remove(product);
    });
  }
}

写法二（不推荐的写法） #

class _ShoppingListState extends State<ShoppingList> {
  Set<Product> _shoppingCart = new Set<Product>();

  void _handleCartChanged(Product product, bool inCart) {
    if (inCart)
      _shoppingCart.add(product);
    else
      _shoppingCart.remove(product);
    setState(() {});
  }
}

直接给结论：在你这个同步操作的简单场景下，两种写法看起来能实现一样的功能，但从Flutter的设计原则、代码健壮性和可维护性来说，差别很大。

为啥这么说？咱拆解一下：

• 首先，Flutter设计setState()的初衷，就是让你把状态修改的逻辑放在它的回调里。这样做能保证状态变更和UI重建是绑定在一起的原子操作——框架会先执行回调里的状态修改，再触发Widget重建，避免中间出现状态不一致的情况。
• 其次，要是把状态修改放在外面，虽然当前例子是同步代码没问题，但万一后面加了异步逻辑（比如网络请求后改状态），或者不小心在修改状态和调用setState之间插入了其他影响状态的代码，很容易出现“UI显示的状态和实际内存里的状态对不上”的bug，排查起来贼麻烦。
• 最后，从代码可读性来说，写法一的意图一目了然：“这段代码是修改状态并触发重建”，其他开发者看一眼就懂；而写法二得反应一下——哦，原来先改了状态再通知重建，时间长了容易忘，维护成本高。

所以啊，哪怕两种写法在当前场景下效果一样，也一定要坚持写法一这种符合官方规范的方式，别给自己埋坑。

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