当你旋转手机测试屏幕时，布局会适应或崩溃。文本重新排列，按钮跳跃，模态窗口突然覆盖错误区域，或者你的视频播放器表现得恰到好处。 横屏 不再是设计术语，而是产品决策。
如果你在开发移动应用，需要明确的答案： 横屏是什么。不仅仅是课堂上的定义，还有开发者的版本。它如何影响布局，何时支持旋转，何时锁定它，以及如何在Web应用、原生应用和Capacitor项目中处理它，避免创建脆弱的用户体验。
目录
- 理解横屏
- [Portrait vs Landscape] A Fundamental Comparison
- [Common Use Cases Across Different Media]
- [Handling Orientation on the Web]
- 在移动应用中管理方向
- 移动方向旋转最佳实践
了解横屏方向
用户首先注意到方向旋转时屏幕旋转。开发者则注意到旋转破坏了他们的界面。
横屏方向 意味着框架的高度大于宽度 。这就是核心概念。它来自视觉艺术，人们通常将人物面部和上半身的肖像画成垂直框架。同样的概念也延伸到了页面设计、摄影和数字界面。一个好的参考来源是更广泛的历史背景是']} 移动方向旋转的最佳实践 Wikipedia的页面方向概述.
对于开发者来说，重要的是，横向方向不是与一个屏幕尺寸、一个设备或一个文件格式相关联的。它是一个关于形状的规则。如果高度大于宽度，你就处于横向方向。
在产品工作中为什么它很重要
横向方向成为移动设备的实际默认值，因为直立使用与人们自然地握持手机的方式相符。这会影响滚动、拇指触摸、阅读流、表单设计和导航位置的布局。
一个feed、文章视图、设置屏幕或聊天线程通常在垂直框架中阅读得更自然。这是为什么方向选择直接与 移动应用程序用户体验决策而不仅仅是视觉样式有关的原因。
实用规则： 将横向方向视为布局上下文，而不是仅仅是设备位置。
初级开发者容易混淆的地方
混淆的通常是 方向 with 分辨率 或 宽高比. They’re related, but they aren’t the same thing.
- 方向 分辨率
- 描述了每个维度中存在的像素数量。 宽高比
- 描述了宽度和高度之间的关系。 在竖屏模式下，平板电脑和手机可能具有不同的尺寸，但它们仍然共享相同的方向状态。因此，应在询问任何更具体的问题之前先问：‘高度是否大于宽度？’
__CAPGO_KEEP_0__
人像 vs 横向 A 基本比较
从组成的角度来看，这很简单。人像画的重点是聚焦在一个人或另一个高个子的主体上。横向画则捕捉宽度、背景和周围空间。UI 的工作方式与此相同。
在图像和 UI 设计中，人像方向是矩形，其中 高度大于宽度,所以更长的边是垂直的。这与横向方向相反。 SLR Lounge 的词汇条目 解释了技术定义以及这种形状为什么适合于高个子和垂直结构。
在一张表格中，唯一的区别是
| 方向 | 形状 | 最佳匹配 | 典型效果 |
|---|---|---|---|
| 人像 | 高于宽 | 订阅、表单、阅读、高体积 | 垂直吸引注意力 |
| 横屏 | 宽于高 | 视频、地图、仪表盘、宽场景 | 显示更多水平上下文 |
听起来很基础，但在产品评估时很有用。
对用户的变化
人像通常会缩小注意力。它减少了侧边内容并鼓励从上到下的流动。这就是为什么社交订阅、文章页面、引导步骤和聊天界面通常在人像模式下看起来更干净的原因。
水平方向则相反。它暴露了更多的宽度，这有助于分屏视图、时间线、画廊、媒体播放、数据密集型表面和沉浸式视图。如果您的布局需要横向比较，这种水平格式通常会给您更多的呼吸空间。
通常来说，竖屏是关于聚焦，横屏是关于背景。
开发者需要做出的改变
开发者最大的错误是把更宽的格式当作竖屏的拉伸版本。它不是。信息层次结构通常需要改变。
例如：
- 在竖屏模式下，一个仪表板可能将卡片堆叠成一个单独的列。在更宽的方向下，同一个仪表板可能会转变为多列，并显示过滤器或侧边面板。
- 在竖屏模式下，一个支付表单可能会优先考虑大型点击目标和一个清晰的流程。在更宽的方向下
- In a wider orientation, the same dashboard might shift to multiple columns and reveal filters or side panels.
- In portrait即使在字段垂直压缩时，同一屏幕也会感到不适。
开发者在处理沉浸式移动布局时，还需要考虑边缘处理、安全区域和全屏行为。如果您正在调整这些细节， Capacitor 全屏幕显示设置 是同一对话的组成部分，因为屏幕方向如何影响用户感知的可用空间。
不同媒体的常见用例
垂直屏幕在更多场景中出现，超过了移动设备。这种概念并不是在软件中开始的，也不仅仅是软件的范畴。
摄影和印刷
专业头像是最明显的例子。垂直框架更适合捕捉人脸和身体，而宽框架则不然。同样的逻辑适用于时尚照片、书籍封面、海报和杂志封面。
印刷设计也依赖于垂直屏幕，当阅读体验应该从上到下在狭窄的列中移动时。这种形状有助于眼球自然地沿着页面向下移动。
文件和日常交流
大多数报告、简历、信件和内部文档都是以垂直屏幕设计的。这不是因为垂直屏幕总是更好，而是因为垂直页面在阅读段落、标题、列表和签名的序列时效果更好。
如果你曾经导出过PDF并注意到一个宽表格突然变得难以阅读，你就已经遇到了横向模式的限制。有些内容更适合在水平格式中呈现。关键是匹配框架到内容结构。
移动产品和应用流程
在这种情况下，横向模式成为许多团队的默认心理模型。
思考一下用户打开的重复屏幕：
- 聊天应用： 消息堆叠在一起垂直排列。
- 社交应用： 帖子、评论和短视频在竖直流程中被消耗。
- 零售应用： 搜索结果和产品列表向下滚动。
- 银行应用： 余额、交易和确认流程通常以垂直部分排列。
那些模式并不是巧合。Portrait支持单手操作、手指滚动和线性任务完成。
许多移动UI看起来很直观，因为界面假设一个直立设备，然后假设其他任何东西。
这并不意味着每个屏幕都应该保持直立。媒体播放器、地图、大型图表和基于相机的工作流程往往从更宽的布局中受益。但是，对于日常任务流程，直立通常是用户开始的地方。
Web端处理屏幕方向
一个常见的Web bug看起来很小。您的应用程序在直立视图中清晰阅读，然后用户旋转设备，图表溢出，侧边栏出现在错误的断点处，键盘覆盖提交按钮。Web端的屏幕方向实际上是关于状态。视口形状发生了变化，您的UI需要以可预测的方式响应。
对于开发者来说，这意味着分离两个任务。CSS处理布局变化。JavaScript处理行为变化。如果您将同一项目打包为移动应用程序，这个Web层仍然很重要。 使用Capacitor将Web应用程序转换为移动应用程序 并不消除了良好的Web屏幕方向处理的需求。它使这个基础更为重要。
该平台提供了两个主要工具。屏幕方向API暴露了屏幕方向类型和更改事件，Web应用程序清单允许安装的应用程序声明一个首选的直立模式，如"portrait"或"landscape"。 portrait, portrait-primaryMDN文档了清单值的使用方法在其 portrait-secondaryWeb App Manifest屏幕方向参考 Web App Manifest orientation reference.
使用 CSS 时，布局应适应
从 CSS 开始。它是最便宜和最可靠的方法来响应宽度和高度互换时的变化
/* Default portrait-friendly layout */
.page {
display: grid;
grid-template-columns: 1fr;
gap: 16px;
}
.sidebar {
display: none;
}
@media (orientation: landscape) {
.page {
grid-template-columns: 280px 1fr;
}
.sidebar {
display: block;
}
}这与屏幕形状的渐进增强一样。以窄屏竖直布局作为默认值，然后在视口变宽时添加仅用于次要 UI 的空间
几个实践可以节省后期时间：
- 从主要模式开始： 如果人们主要使用竖屏应用，设定竖屏布局为基础
- 避免固定高度： 旋转设备可以迅速缩小可用垂直空间，尤其是当浏览器 UI 或虚拟键盘可见时
- 测试真实的交互状态： 表单、粘性标题和底部sheet在旋转时经常会失败，而不是在静态截图中
使用 JavaScript 时，行为必须反应
CSS 可以重新排列盒子。它无法决定重建图表或重置手势处理器时何时执行
当屏幕旋转时，使用 JavaScript 来处理状态 UI 的变化。
function logOrientation() {
const type = screen.orientation?.type;
console.log('Current orientation:', type);
}
logOrientation();
screen.orientation?.addEventListener('change', () => {
logOrientation();
const isPortrait = window.innerHeight > window.innerWidth;
if (isPortrait) {
document.body.classList.remove('wide-mode');
} else {
document.body.classList.add('wide-mode');
}
});对于画布、媒体控制、地图视图和自定义导航壳，这种模式很有用。这种思维方式很简单。如果旋转改变了数据的呈现方式或交互逻辑，JavaScript应该做出反应。如果旋转仅仅改变了间距或位置，CSS就应该处理它。
在 junior 团队中，一个实用的规则可以帮助他们避免很多复杂性。不要使用 JavaScript 强制布局决策，这些决策 CSS 已经能够很好地处理。
为 PWA 设置首选方向
如果您的PWA主要用于直立使用，请在manifest中声明。
{
"name": "My App",
"short_name": "MyApp",
"display": "standalone",
"orientation": "portrait"
}在支持的上下文中，这个设置帮助浏览器了解已安装应用程序应该如何打开和行为，而不是响应式设计的替代品。
您也可以在浏览器允许的情况下，在运行时请求一个方向锁定：
async function lockPortrait() {
try {
await screen.orientation.lock('portrait');
console.log('Orientation locked');
} catch (err) {
console.log('Lock failed:', err);
}
}在使用时要谨慎。一个好的规则是，只在旋转可能会破坏任务本身的情况下锁定，如导引式捕获流程或具有严格物理对齐要求的屏幕。在其他大多数情况下，适应界面是更好的工程选择，因为它尊严于设备和用户。
在移动应用中管理方向
移动应用程序可以做的比浏览器标签更多。它们可以在应用程序级别声明一个默认的屏幕方向，然后在任务需要时为单个屏幕改变行为。这种额外的控制是有用的，但它也会导致一个常见的错误。团队会过度限制旋转，一个简单的应用程序会感到僵硬。
一个好的心理模型在这里很有帮助。 App-wide 设置是您的默认策略。 屏幕级别 code 是例外层。 使用策略来实现广泛的意图，仅在旋转设备会干扰用户完成任务时使用例外。
原生平台控制
开启 Android,屏幕方向通常在 AndroidManifest.xml 中设置：
<activity
android:name=".MainActivity"
android:screenOrientation="portrait" />这就像一个顶级配置标志。 它简单、可预测、易于在整个活动中实施。 但是，范围的权衡是：如果只有一屏幕需要直立模式，应用该规则全球通常太过粗糙。
开启 iOS,支持的屏幕方向在 Xcode 中通过目标设置和应用元数据设置。 您可以定义应用支持的总体设置，然后在特定视图控制器中细化屏幕的要求。
这对于跨平台团队来说很重要。 原生配置回答，“这个应用应该允许什么？” 运行时 code 回答，“这个屏幕应该做什么？”
程序化控制在Capacitor应用中
如果您使用Capacitor构建应用，动态控制通常应该放在code，靠近需要它的路由或视图。登录屏幕可能更容易在横屏下使用，而媒体屏幕或摄像头流可能需要允许根据设备的姿势旋转。
插件可以使该逻辑可读并避免自定义本机管道。 Capacitor屏幕方向Capacitor应用的插件 让您读取当前方向，应用特定模式（如横屏）时的限制，并在用户返回到灵活屏幕时移除该限制。
import { ScreenOrientation } from '@capgo/capacitor-screen-orientation';
async function lockLoginScreen() {
await ScreenOrientation.lock({ orientation: 'portrait' });
}
async function unlockForMedia() {
await ScreenOrientation.unlock();
}
async function checkCurrentOrientation() {
const result = await ScreenOrientation.orientation();
console.log(result);
}模式很简单。 在屏幕激活时应用限制，在屏幕不再激活时移除。在基于路由器的应用中，这通常意味着将方向变化与页面生命周期钩子相关联，而不是在随机组件中散布调用。
选择屏幕特定限制时要小心
在旋转会干扰输入、对齐或用户焦点时使用固定直立模式。
常见的例子包括：
- 身份验证屏幕： 输入保持稳定，用户输入时不受影响。
- 支付和确认步骤： 在高注意力任务中发生的布局变化越少越好。
- Kiosk 或引导式工作流程： 界面需要一致的呈现方式。
当额外宽度或不同的握持方式显著地有助于任务时，让设备自由旋转。
典型的例子包括媒体播放、地图、游戏、相机视图和密集数据屏幕。
对于初级团队来说，一个有用的规则是简单的。如果改变设备方向只会改变间距，让布局系统处理它。如果改变设备方向会改变任务的工作方式，那么屏幕级别的方向code可能是合理的。
Capgo 在这里提及的原因是实用性的。在 Capacitor 项目中，方向控制是那些从小的 UI 详情迅速成为应用行为的平台功能之一。将其视为行为。保持默认值灵活，适度应用限制，并在屏幕不再需要它们时移除它们。
屏幕方向的 UX 最佳实践
方向处理是一个 UX 决策，技术决策是第二位的。code 通常是简单的。困难的是选择感觉自然的行为。
一个简短的检查清单有助于：
- 为主要上下文进行设计： 如果大多数用户从直立开始，设定横向为界面最强大的版本。
- 支持更广泛的显示模式： 不在那些能从额外宽度中受益的屏幕上阻止旋转：
- 只锁定有明确理由： 表单、结帐或安全流程可能会合理化它。内容屏幕通常不会。
- 在旋转时保留状态： 用户不应该丢失输入、滚动位置或选中的标签页。
- 在真实设备上测试两种方向： 模拟器会错过不适当的过渡、键盘重叠和安全区域问题。
为了更广泛的布局决策， Capacitor 应用程序的跨平台 UI 和 UX 指南 适合与方向测试一起使用，因为同一屏幕通常需要在不同设备大小和平台约定中感觉像家一样。
主要的收获很简单。如果你问的是什么是竖屏方向，那答案不是仅仅是“垂直”。它是一个框架规则、一个布局状态和一个用户期望。好的应用程序会以这种方式对待它。
如果您正在发布Capacitor应用并需要控制方向行为以及快速的发布修复， Capgo 值得一看。它为CapacitorJS和Electron应用提供实时更新，并且它还维护了屏幕方向等应用能力的插件，
