Flutter无限大小冲突及Cors问题

Posted on 2025-02-18 Edited on 2025-02-21 Views:

这两天遇到的两个问题，记录下。

一句话总结

infinite size conflict: 一个要求无限充满的组件，和一个要求水平滚动的组件，放在一起，就会导致无限大小冲突。
cors: 一般的 dio 请求，都能正常使用，但是用 chrome 运行 web 项目时，会报错，这是因为 chrome 的安全策略，不允许跨域请求。

无限大小冲突

prompt 0:

给我来一个最小例子展示，无限大小冲突问题，并用比喻或者容易理解的方式来解释问题的本质。最好是expanded嵌套row和column，然后循环嵌套的例子

prompt 1:

不要显示的用double.infinity和constrained: false 来制造冲突，就用InteractiveViewer，确实需要“超大宽度”或“无限延伸”来实现这个例子

o1 想了1分钟，就给出了答案，不要显示的用double.infinity和constrained: false 来制造冲突，就用InteractiveViewer，确实需要“超大宽度”或“无限延伸”来实现这个例子

Reasoned for 1m 13s
Pondering the conflict
I’m working on an example using InteractiveViewer, Row, Expanded, and Column, aiming to trigger an infinite size conflict without directly setting double.infinity or constrained: false.
Crafting the scenario
Piecing together a large horizontal view with InteractiveViewer in a Row + Expanded layout. It’s tricky to recreate infinite size conflicts without using specific constraints like double.infinity or constrained: false.
Building the structure
I’m creating a Row with Expanded, a Column, another Row, and an Expanded with an InteractiveViewer. This setup examines if a SingleChildScrollView or Horizontally expanding ListView can cause infinite size conflicts.
Assessing potential conflicts
I’m looking at how using a SingleChildScrollView with a Row might cause “unbounded width.” Pinch-to-zoom on a wide map or large image in an InteractiveViewer could trigger infinite size conflicts.
Strategizing layout
I’m curious about settings like swelling a large Image.asset or using AspectRatio with a high aspect ratio. These might instigate an infinite size conflict in the layout.
Adjusting my approach
Considering how InteractiveViewer handles unbounded content scaling and exploring super-aspect ratio settings to create an infinite layout scenario without using explicit constraints.
Designing layout structures
I’m working through creating scenarios where layouts attempt to expand beyond their constraints, possibly using SingleChildScrollView to handle unbounded constraints in horizontal scrolling.
Navigating infinite layout
I’m piecing together an infinite size conflict scenario by using LayoutBuilder to recursively adjust layout with constraints, ensuring it tackles unbounded layouts without hardcoding constraints.
Aligning with constraints
I’m looking at how a nested InteractiveViewer within a SingleChildScrollView can breach finite constraints set by a parent Row or Expanded, leading to an unbounded layout.
Navigating infinite layout
I’m outlining scenarios with nested InteractiveViewer and SingleChildScrollView that might trigger infinite layout issues without directly using double.infinity or constrained: false.
Crafting layout conflict
Integrating InteractiveViewer and SingleChildScrollView might create a finite layout issue, avoiding explicit double.infinity or constrained: false. This approach effectively manages layout constraints.
Tackling layout constraints
I’m working through how certain configurations, like minScale and maxScale in InteractiveViewer, can inadvertently create infinite layout problems during initial setup rather than through user actions.
Adjusting initial scale
Setting TransformationController to scale by 100 ensures the InteractiveViewer child starts extremely large, potentially causing significant layout issues right from the initial rendering.
Evaluating overflow potential
I’m considering how setting the TransformationController to a large scale in InteractiveViewer might lead to an overflow error due to excessive content size, without necessarily triggering an infinite layout error.
Integrating conflicting elements
I’m thinking about how InteractiveViewer and unbounded constraints from elements like Column, Row, and Expanded might cause layout conflicts, wanting to avoid OverflowBox or double.infinity.
Crafting a layout
I’m assembling a scenario with InteractiveViewer and unbounded constraints, like Row and SingleChildScrollView without horizontal constraints, to potentially trigger an “infinite size” error.
Determining constraints
I’m looking at how a Column within an Expanded might pass down unbounded constraints in the cross-axis, potentially conflicting with InteractiveViewer’s size requirements.
Evaluating layout strategies
I’m weighing how combining Row, Column, and InteractiveViewer can create a bounded vertical dimension or a SingleChildScrollView for a large child row to potentially trigger an error.
Bringing interactive elements
I’m examining how wrapping PageView or ListView with InteractiveViewer might trigger “RenderConstrainedOverflowBox was given an infinite size,” especially if the child isn’t restricted in the main axis.
Triggering infinite size
I’m thinking about how a widget in a Column with Expanded might pass unbounded width constraints to InteractiveViewer, potentially causing an “infinite size” conflict due to the lack of width boundaries.
Identifying conflict
Wrapping a Column in SingleChildScrollView and Expanded can trigger an “infinite size” error due to constraints overlapping between the scrollable and Expanded widgets.
Evaluating layout constraints
Wrapping a Column with InteractiveViewer and SingleChildScrollView might lead to “RenderFlex overflowed” or “RenderConstrainedOverflowBox was given an infinite size” due to conflicts in layout constraints.
Analyzing horizontal constraints
Wrapping a SingleChildScrollView with a Column might lead to horizontal unbounded constraints, causing the Expanded widget to stretch infinitely and potentially trigger errors.
Navigating layout constraints
Using a horizontal SingleChildScrollView or a vertical one with a Row inside can lead to the Expanded widget trying to fill infinite space, causing layout conflicts.
Detecting layout conflicts
I’m working through a minimal Flutter example to trigger horizontal scroll issues with Row, SingleChildScrollView, and Expanded, leading to errors due to unbounded width constraints.
Revisiting layout constraints
Considering a practical scenario like a map viewer or diagram viewer, which inherently requires expansive dimensions that lead to conflicts when using Row, SingleChildScrollView, and Expanded.
Managing large models
Balancing large models and layout constraints can lead to errors. Controlling model size and wisely using Expanded and InteractiveViewer can help manage unbounded and infinite space conflicts.
Balancing layout constraints
I’m thinking through how to manage layouts with large children or infinite sizes without using double.infinity or constrained: false, focusing on effective constraint alignment.
Balancing constraints
I’m integrating a horizontal list within an InteractiveViewer and Expanded components, all while navigating the challenges of layout constraints and potential unbounded extensions.
Navigating layout issues
Utilizing Expanded and InteractiveViewer can lead to overflow or clip errors if content exceeds constraints. Tweaking settings like scaleEnabled and boundaryMargin might provide a solution.
Addressing constraints
To step back and think it through: trying out large children in InteractiveViewer with Expanded often triggers layout conflicts. Sometimes, setting double.infinity or constrained: false is needed to resolve unrestriction issues.
Evaluating SVGs and custom painters
I’m thinking about how large SVGs or custom painters might not trigger infinite layout errors unless bounds are explicitly set or the painter lacks certain implementations.
Testing infinite constraints
Housing a large CustomPainter in an InteractiveViewer with FittedBox ensures boundless layout issues are carefully evaluated. Progress is steady as I set up the scenario.
Spotting layout triggers
Wrapping a Row in an Expanded within a horizontal SingleChildScrollView often sparks layout errors like “RenderConstrainedOverflowBox object was given an infinite size.”
Testing layout flow
I’m setting up a HorizontalSingleChildScrollView with a Row and InteractiveViewer to identify triggers for “RenderConstrainedOverflowBox object was given an infinite size” in Flutter.
Integrating components
Using a Row and Expanded within SingleChildScrollView to handle “RenderConstrainedOverflowBox” errors. This setup is essential for managing unbounded width constraints in Flutter layouts.
Wrapping up the code
I’m piecing together a minimal example with SingleChildScrollView, Row, Expanded, and InteractiveViewer to resolve layout errors like “RenderConstrainedOverflowBox.”
Ensuring error handling
Wrapping up the SingleChildScrollView and Row to Expanded and InteractiveViewer setup, I’m focusing on preventing “RenderConstrainedOverflowBox” by confirming proper constraints.
Spotting layout conflicts
Mapping out the SingleChildScrollView and Row setup with Expanded and InteractiveViewer, I’m making sure to avoid “RenderConstrainedOverflowBox” errors by managing unbounded width.

下面给你一个最小可复现的示例，使用 InteractiveViewer 场景中“确实需要超大宽度/无限延伸”来展示在 Flutter 布局中可能触发的「给了子组件无限大小」冲突。
关键点在于：我们想要做一个可横向滚动的视图（用 SingleChildScrollView(scrollDirection: Axis.horizontal)），里头又放了一个 Row，并且其中有一个 Expanded 包裹着 InteractiveViewer。这就会形成 Row（水平方向）+ Expanded（想填满父组件）+ 横向滚动（父组件本身宽度不受限制） 的典型冲突场景，往往会报出类似：

RenderConstrainedOverflowBox object was given an infinite size during layout.

或

BoxConstraints forces an infinite width.

这类「无限大小」的错误。

最小示例代码

将以下代码直接运行在一个新的 Flutter 工程中，你就有较高概率在控制台看到相应的错误信息：

import 'package:flutter/material.dart';

void main() {
  runApp(const MaterialApp(home: InteractiveViewerInfiniteExample()));
}

class InteractiveViewerInfiniteExample extends StatelessWidget {
  const InteractiveViewerInfiniteExample({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: SingleChildScrollView(
        scrollDirection: Axis.horizontal, // 1. 横向滚动
        child: Row(
          children: [
            // 先放一些固定宽度的蓝色方块，制造“宽内容”
            for (int i = 0; i < 3; i++)
              Container(
                width: 300,
                height: 300,
                color: Colors.blue,
                margin: const EdgeInsets.all(8),
                child: Center(
                  child: Text(
                    'Item $i',
                    style: const TextStyle(color: Colors.white),
                  ),
                ),
              ),
            // 2. 在 Row 中使用 Expanded + InteractiveViewer
            Expanded(
              child: InteractiveViewer(
                child: Container(
                  height: 300,
                  color: Colors.red,
                  child: const Center(
                    child: Text(
                      'Zoomable Content',
                      style: TextStyle(color: Colors.white),
                    ),
                  ),
                ),
              ),
            ),
          ],
        ),
      ),
    );
  }
}

为什么会报错？

SingleChildScrollView(scrollDirection: Axis.horizontal) 会让内部在水平尺寸上不再受屏幕固定宽度的约束（它可以滚动得比屏幕更宽）。
里面的 Row 在水平方向得到的约束是“未限定的宽度” (unbounded width)。
然而 Row 中又有一个 Expanded 子组件，这代表“我要在主轴方向尽可能扩大，填满剩余空间”。可此时剩余空间其实是 “∞” （因为外层滚动视图不限制宽度），Expanded 就会尝试去占一个“无限宽度”。
InteractiveViewer 内部为了可平移/缩放，使用了类似 OverflowBox 的机制来绘制其子组件，当它拿到 “无限宽度” 时，自然就会导致「给了子组件无限大小」的冲突，从而触发报错。

简而言之：在可横向滚动的环境中，再使用 Row + Expanded，就会令 Expanded 获得“无界”约束，Flutter 无法计算其实际宽度，于是就出现了「无限大小冲突」。

用“电影院座位”来比喻

SingleChildScrollView(横向) ：像一个可无限加长的“走廊”或“可延伸”的电影院排区，“你可以排得很长很长”。
Row：就像一排座位，但这排座位没有固定的总长度（因为可以一直往后延伸）。
Expanded：某位观众说，“我要把这一排剩下的所有位子都占满。”
但这排其实可以一直向后延伸（因为滚动不设限） -> “那剩下的座位就无限多” -> 观众就陷入了“想要∞”的状态。
InteractiveViewer：还自带可拖拽、缩放功能，相当于观众还想随意变换姿势，内部实现依赖了“可溢出的布局组件” (类似 OverflowBox)，就进一步放大了这个问题。

最终，排长（Flutter 布局）发现没法同时满足“无限延伸”又要“占满剩余空间”的矛盾，报错退出。

如何避免或修复？

不要在横向可滚动的 Row 中再使用 Expanded
- 如果你一定要横向滚动，就改用固定宽度或自适应宽度的子组件，而不使用 Expanded。
- 比如给那个红色区域一个具体宽度（如 300）或包裹在 SizedBox(width: someFixedValue) 里；或者使用 Flexible 并指定 fit: FlexFit.loose 等方式来让它只占所需空间。
如果你真想让某个部分随父容器大小自适应
- 那就不要把它放进一个“水平无限可滚动”的容器里，可以把它放在一个有固定或最大宽度限制的父组件中。
在需要大面积缩放的场景下
- 推荐用 InteractiveViewer，但最好让它在一个有确定大小的容器里，或者配合滚动控件“在不同轴”进行滚动和缩放，而不是直接让外层再给它一个“无限宽度”的水平方向。

结论

本质：父组件给了子组件“未受限制（∞）”的宽度，但子组件还想“填满”这无限宽度 -> 布局计算就无法完成，触发 RenderConstrainedOverflowBox was given an infinite size。
一条经验：如果你在水平方向用 SingleChildScrollView（或 ListView 横向滚动），里面的 Row 就千万别再给任何子组件 Expanded，否则就是一个典型的“无限大小冲突”场景。

希望这个示例能帮助你理解在 Flutter 中 InteractiveViewer 与滚动、布局约束交互时出现的“无限大小”问题，以及该如何在实际项目中规避。祝你开发顺利!

cors 问题

顺便提下，一般的 dio 请求，都能正常使用，但是用 chrome 运行 web 项目时，会报错，这是因为 chrome 的安全策略，不允许跨域请求。

请求失败: DioException [connection error]: The connection errored: The XMLHttpRequest onError callback was called. This typically indicates an error on the network layer. This indicates an error which most likely cannot be solved by the library.

解决办法：
安装一个flutter_cors | Dart package插件，可以解决这个问题。

# 安装
$ dart pub global activate flutter_cors
# 使用
$ fluttercors --disable
$ fluttercors --enable