前端页面与布局术语：从 P1–P4 到 fill / content

① 先把后文会反复出现的词认清楚

先认清后文会承担推理作用的核心词。这里不是词典，而是最小术语闭包。

② 现在再看这段材料到底在说什么

一句话：一个前端页面不能只用“这是哪个页面”来描述。至少要同时回答六个问题：它是什么信息、在哪一层、怎么到达、以什么容器呈现、现在处于什么状态、空间与滚动怎么管理。

你可以把这一整套模型看成“前端页面的坐标系”：结构、导航、呈现、状态和布局是不同坐标轴。两个页面可以同为 P2，却一个是 content，另一个是 fill；同一个 P3 页面也可以既通过上下文导航进入，也可以通过 deep link 直接到达。

③ 概念关系与最小知识闭包

先分清两张图：“分类关系”回答它属于哪一类；“学习依赖”回答先学什么再学什么。两者不能混用。

学习依赖更适合按下面顺序：

一、先把 'fill' | 'content' 当成一个有限集合

TypeScript 的字符串字面量联合类型可以用集合直觉理解：

type LayoutMode = 'fill' | 'content';

let mode: LayoutMode;
mode = 'fill';      // 合法
mode = 'content';   // 合法
// mode = 'hello';  // 非法

这里的 | 不是“CSS 或者”，而是 TypeScript 类型系统里的 union type（联合类型）：变量只能落在允许值集合里。相比 fill: boolean，layout="content" 更能直接表达领域语义。

二、Sizing：先问“谁决定我的尺寸”

三、Flow：再问“兄弟元素如何排”

四、Positioning：元素是不是还在正常文档流里

五、Overflow：最后问“装不下怎么办”

当容器尺寸受到约束而内容继续增长时，才进入 Overflow 与滚动问题。表单通常希望让 document scroll 承担主滚动；编辑器、地图、聊天消息区更常让某个 container scroll 承担滚动。

④ 把真实案例重新还原

现在套回你正在碰到的真实改造：引入 fill/content 联合类型，并让仪表盘、表单和组织治理页退出 data-fill-rail。

<Page data-fill-rail>
  <Dashboard />
</Page>

type LayoutMode = 'fill' | 'content';

<Page layout="content">
  <Dashboard />
</Page>

⑤ 概念如何映射到现实

把页面语义与布局术语放在同一张表中，你就能像读类型系统一样读前端页面。

三个更工程化的 Shell / Region 词

一条实用判定链

先判断：
Page / App Shell 是什么？
  ↓
内部是 Normal Flow、Flex 还是 Grid？
  ↓
每个区域是 Fixed、Fill 还是 Content？
  ↓
内容超出时谁拥有 Scroll？
  ↓
Viewport 变小时如何 Reflow？

看到 flex:1、min-height:0、overflow:auto、data-fill-rail 同时出现时，通常意味着“应用型 fill 布局 + 内部滚动”这一整套策略，而不是四个互不相关的属性。

⑥ 现在把它当成一道题

假设 AthleteOS 有下面三个页面。请分别判断它们更适合 fill 还是 content，并指出谁应该是主要 scroll owner。

再回答一个工程题：如果 B 的 Main 区域使用 Flexbox，内部 Pane 设置了 overflow:auto 却仍然把整个页面撑高，你会优先检查哪个常见属性？为什么？

⑦ 分级提示，最后就是实际答案