小更新：When used for whitespace, there is now even a linter warning to prefer SizedBox instead of Container。主要的优点似乎是SizedBox可以是const，甚至在运行时不会创建新的示例。
多亏了开源的魔力，你不必猜太多。
Container基本上只是一个方便的小部件，有时候可以节省嵌套4个其他小部件的时间。

constraints =
        (width != null || height != null)
          ? constraints?.tighten(width: width, height: height)
            ?? BoxConstraints.tightFor(width: width, height: height)
          : constraints,

这将导致：

if (constraints != null)
      current = ConstrainedBox(constraints: constraints, child: current);

实际上，ConstrainedBox与SizedBox几乎相同，只是更灵活。
一个SizedBox可以：

@override
  RenderConstrainedBox createRenderObject(BuildContext context) {
    return RenderConstrainedBox(
      additionalConstraints: _additionalConstraints,
    );
  }

  BoxConstraints get _additionalConstraints {
    return BoxConstraints.tightFor(width: width, height: height);
  }

也就是说，它实际上是相同的。如果你只使用Container的宽度/高度，可能会有一个非常小的微不足道的性能开销。但你肯定无法衡量它。但我仍然会推荐SizedBox，因为它的方式更清晰。imho。

我想补充的是，SizedBox不仅更简单，而且还可以变成const，而Container则不能。
如果你需要一个有颜色的盒子，你不能使用SizedBox，但是https://pub.dev/packages/assorted_layout_widgets有Box小部件，它介于SizedBox和Container之间：你可以有颜色，它可以做const . * 注意我是这个包的作者.*

**SizedBox（）**是一个小部件，用于在两个小部件之间提供一些恒定的高度或宽度。它不包含任何装饰属性，如颜色、边界半径等。

另一方面，**Container（）**是一个小部件，任何人都可以根据自己的需要进行修改。
只要浏览一下这两个小部件的属性，您就会看到它们之间的巨大差异。

SizedBox和Container创建一个RenderObject。RenderObject位于渲染树中，即使它在屏幕上不绘制任何内容，也会对其执行一些计算。
我们可以做得更好，我们可以有一个小部件，它不创建一个RenderObject，但仍然有效。Nil小部件是这个用例的最小实现。它只创建一个Element，在构建的时候什么也不做。因为使用它的最佳方式是调用const Nil（），它还附带了一个nil常量，你可以在任何地方使用（这是一个const Nil（））。