How does const on a widget constructor impact build and reconciliation?

WHAT THIS TESTS: Whether you understand the distinction between the short-lived widget tree and the long-lived element tree, how Dart const semantics interact with Flutter's reconciliation algorithm, and what actually happens under the hood during a build when widget references do not change.

A GOOD ANSWER COVERS four things in order. First, const constructors canonicalize widget instances at compile time: when you write const Text('hello') in multiple places, Dart guarantees the same object is reused. Second, during reconciliation the framework calls Element.updateChild, which compares the new widget to the old widget by reference. If oldWidget == newWidget, the method returns the existing child element immediately and skips traversing the entire subtree. Third, this optimization reduces garbage collection pressure because fewer widget objects are allocated on each build, and it speeds up diffing because a single reference comparison is instant. Fourth, because the element is reused and no update is performed, the underlying render object is not touched, meaning no layout, paint, or semantics work occurs for that subtree.

COMMON WRONG ANSWERS include saying that const affects the render object directly, confusing widget immutability with element reuse, claiming that const prevents the parent widget from rebuilding, asserting that const widgets are automatically cached by the framework even when the parent passes a different instance, or stating that const is only a style hint with no runtime effect.

LIKELY FOLLOW-UPS are: when should you avoid const constructors; how do const widgets interact with GlobalKey or ValueKey; what happens if a const widget contains non-const children; whether const helps inside a ListView builder; and how const canonicalization behaves across hot reload.

ONE CONCRETE EXAMPLE: imagine a StatefulWidget with an AnimationBuilder that rebuilds every frame. If its child is const Center(child: const Text('Loading')), the framework reuses the exact same Center and Text instances on every frame. During reconciliation, the element sees oldWidget == newWidget and skips both subtrees entirely. If you omit const, new widget instances are created each frame, forcing the element tree to update, creating garbage, and potentially triggering unnecessary layout or paint work in descendants.