你旋转手机测试屏幕时，布局要么适应得很好，要么崩溃。文本重新排列，按钮跳跃，模态窗口突然覆盖了错误的区域，或者你的视频播放器表现得恰如其分。那个小的瞬间是 人像模式 不再是一种设计术语，而是一种产品决策。
如果您正在为移动设备开发应用程序，则需要明确的答案： 什么是肖像模式不仅仅是课堂上的定义，还包括开发者版本。它如何影响布局，何时支持旋转，何时锁定它，以及如何在Web应用程序、原生应用程序和Capacitor项目中处理它，而不创建脆弱的用户体验。
目录
- 理解肖像模式
- 肖像模式与横向模式的基本比较
- Common Use Cases Across Different Media
- Handling Orientation on the Web
- Managing Orientation in Mobile Apps
- UX 最佳实践：屏幕旋转
理解横屏
用户首先注意到屏幕旋转时的方向。开发者则注意到旋转时界面会破裂。
横屏 意味着屏幕的高度大于宽度 。这就是核心概念。它来自视觉艺术，人们通常将人物面部和上半身的肖像画以垂直方式框定。同样的概念也延伸到了网页设计、摄影和数字界面。了解更广泛的历史的一个好参考来源是维基百科的页面方向概述 对于开发者来说，重要的是横屏方向并不是与一个屏幕尺寸、一个设备或一个文件格式相关联的。它是一个关于形状的规则。如果高度大于宽度，你就处于横屏状态.
为什么在产品工作中它很重要
横屏成为移动设备的实际默认值，因为人们自然地将手机举在直立姿势。这种姿势影响了滚动、手指触摸范围、阅读流畅度、表单设计和导航位置的布局。
__CAPGO_KEEP_0__
A feed, article view, settings screen, or chat thread通常在垂直框架中阅读起来更自然。 这是为什么方向选择直接与 移动应用程序用户体验决策相关，而不仅仅是视觉样式
实用规则： 将肖像视为布局上下文，而不是仅仅是设备位置
初级开发人员经常混淆的地方
通常的混淆是混淆 方向 与 分辨率 或 宽高比. 他们是相关的，但不是同一件事。
- Orientation 表示哪一侧更长。
- Resolution 表示每个维度中存在的像素数量。
- Aspect ratio 描述了宽度和高度之间的关系。
一张平板电脑的竖屏和一张手机的竖屏尽管尺寸可能有很大差异，但仍然共享相同的方向状态。这就是为什么响应式UI逻辑应该先问“高度是否大于宽度？”而不是问任何更具体的问题。
竖屏与横屏的基本比较
通过组合来思考，这是一个简单的方法。一个竖屏画作将注意力集中在一个人或另一个高个子的身上。一个横向画作捕捉宽度、背景和周围空间的感觉。UI也一样。
在图像和UI设计中，竖屏方向是矩形的形状， 高度超过宽度所以较长的边是垂直的。与横向排列相反。 SLR Lounge的词汇表条目 描述了技术定义以及为什么这种形状适合高的主体和垂直结构。
一张表格的不同
| 方向 | 形状 | 最佳匹配 | 典型效果 |
|---|---|---|---|
| 竖式 | 高于宽 | 信息流、表格、阅读、高主体 | 专注于垂直方向 |
| 横屏 | 高于宽 | 视频、地图、仪表盘、宽场景 | 显示更多水平上下文 |
听起来很基本，但在产品评估时，这很有用。
对用户的变化
通常，肖像模式会缩小注意力。它减少了侧边内容并鼓励从上到下流动。这就是为什么社交 feeds、文章页面、引导步骤和聊天界面通常在肖像模式下看起来更干净的原因。
横屏模式做了相反的事情。它暴露了更多的宽度，这有助于实现分屏视图、时间线、画廊、媒体播放、数据密集型表面和沉浸式视图。如果您的布局需要横向比较，这种横向格式通常会给您更多的空间。
肖像模式通常是关于专注。横屏模式通常是关于上下文。
对开发者的变化
最大的错误是把更宽的模式当作缩放的肖像模式。它不是。信息层次结构通常需要改变。
例如：
- 在横屏模式下，一个仪表板可能将卡片堆叠成一个单列。
- 在更宽的屏幕模式下，同样的仪表板可能会转换成多列，并显示过滤器或侧边栏。
- 在横屏模式下，一个支付表单可能优先考虑大型触摸目标和一个清晰的流程。
- 在更宽的屏幕模式下，同样的屏幕可能会感到不适当，如果字段变得太过垂直压缩。
开发者在工作于沉浸式移动布局时，也需要考虑边缘处理、安全区域和全屏行为。如果您正在调整这些细节， Capacitor 全屏幕显示设置 是同样的讨论的一部分，因为屏幕方向会影响用户对可用空间的感知。
多媒体场景下的常见用例
在软件以外的概念中，竖屏显示比移动屏幕更常见。这很重要，因为概念并没有始于软件，而且它也只属于软件。
摄影和印刷
专业头像是最明显的例子。垂直框架比宽框架更适合一个人脸和身体的尺寸。同样的逻辑适用于时尚照片、书籍封面、海报和杂志封面。
印刷设计也依赖于竖屏，当阅读体验应该从上到下在狭窄的列中移动时。这种形状有助于眼球自然地向下移动页面。
文件和日常交流
大多数报告、简历、信件和内部文档都是以竖屏设计的。这不是因为竖屏总是更好，而是因为垂直页面在阅读段落、标题、列表和签名的序列时效果很好。
如果您曾经导出PDF并注意到宽表格突然变得不可读，那么您就见证了竖屏的局限性。有些内容在水平格式下更好呈现。关键是匹配框架与内容结构。
移动产品和应用流程
在这些情况下，竖屏成为许多团队的默认心理模型。
想想用户打开的重复屏幕：
- {"targetLanguage":"Simplified Chinese","protectedTokens":["Cloudflare","Capacitor","GitHub","Capgo","code","API","SDK","CLI","npm","bun"],"texts":["","","","","","","","",""],"translations":["","","","","","","","",""],"placeholders":[]} "Chat apps:",""
- "Social apps:","" "Retail apps:",""
- "Banking apps:","" "Those patterns aren’t accidents. Portrait supports one-handed use, thumb scrolling, and linear task completion.",""
- "A lot of mobile UI feels intuitive because the interface assumes an upright device before it assumes anything else.","" "That doesn’t mean every screen should stay portrait. Media viewers, maps, large charts, and camera-based workflows often benefit from wider framing. But for everyday task flow, portrait is usually where users begin.",""
"Handling Orientation on the Web"
""
""
""
A common web bug looks small at first. Your app reads cleanly in an upright viewport, then the user rotates the device and the chart overflows, the sidebar appears at the wrong breakpoint, or the keyboard covers the submit button. Orientation on the web is really about state. The viewport shape changed, and your UI needs to respond in a predictable way.
对于开发者来说，这意味着分离两个任务。 CSS 处理布局变化。 JavaScript 处理行为变化。 如果您将同一项目打包到移动设备上，这个 web 层仍然很重要。 使用 Capacitor 将 web 应用转换为移动应用 这并不消除了良好的 web 方向处理的需求。它使这个基础更为重要。
该平台提供了两个主要工具。 Screen Orientation API exposing 方向类型和变化事件，和 Web App Manifest 让安装的应用程序声明一个首选的直立模式，如","或","。 MDN 文档了那些清单值在其"Web App Manifest 方向参考"中 portrait, portrait-primary使用 CSS 时应适应布局 portrait-secondary从 CSS 开始。它是最便宜和最可靠的方式来响应宽度和高度互换角色。 这与屏幕形状的渐进增强一样。首先以窄直的布局作为默认值。然后在视口变宽时才添加辅助 UI 的空间。.
几个实践可以节省后期时间：
Use CSS when the layout should adapt
/* 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;
}
}Start with CSS. It is the cheapest and most reliable way to respond when width and height swap roles.
This works like progressive enhancement for screen shape. Begin with the narrow, upright layout as the default. Then add room for secondary UI only when the viewport becomes wider.
- 在你的主要模式中开始： 如果人们主要使用应用程序直立，设定该应用程序的基本布局。
- 避免固定高度： 旋转设备可以迅速缩小可用的垂直空间，尤其是在浏览器 UI 或虚拟键盘可见时。
- 测试真实的交互状态： 表单、粘性标题和底部sheet在旋转时经常会失败，而不是在静态截图中。
在行为必须响应时使用 JavaScript：
CSS 可以重新排列盒子，但无法决定何时重建图表或重置手势处理器。
在设备旋转时影响状态UI的场景中使用 JavaScript：
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 应该处理它。
一条实用的规则可以帮助初级团队避免很多复杂性。不要使用 JavaScript 强制 CSS 已经很好地处理的布局决策。
为 PWA 设置一个首选方向
如果您的PWA主要用于直立使用，请在manifest中声明。
{
"name": "My App",
"short_name": "MyApp",
"display": "standalone",
"orientation": "portrait"
}在这种情况下，使用Capacitor并不是响应式设计的替代品，而是一种帮助浏览器了解已安装应用程序在支持的上下文中如何打开和行为的偏好。
您也可以在浏览器允许的情况下，在运行时请求一个方向锁定：
async function lockPortrait() {
try {
await screen.orientation.lock('portrait');
console.log('Orientation locked');
} catch (err) {
console.log('Lock failed:', err);
}
}在使用时要谨慎。一个好的规则是，只在旋转可能会破坏任务本身的情况下锁定，如导引式捕获流程或具有严格物理对齐要求的屏幕。在其他大多数情况下，适应界面是更好的工程选择，因为它尊严于设备和用户。
在移动应用中管理屏幕方向
移动应用程序可以做的比浏览器标签更多。它们可以在应用程序级别声明一个默认的屏幕方向，然后在任务需要时为单个屏幕改变行为。这种额外的控制是有用的，但它也会导致一个常见的错误。团队会过度限制旋转，一个简单的应用程序会感到僵硬。
一个好的心理模型在这里很有帮助。应用级别的设置是你的默认策略。屏幕级别code是例外层。使用策略来实现广泛的意图，仅在旋转设备会干扰用户正在尝试完成的工作时使用例外。
原生平台控制
在 安卓,方向通常是在 AndroidManifest.xml 为活动：
<activity
android:name=".MainActivity"
android:screenOrientation="portrait" />这就像一个顶级配置标志。它简单、可预测、易于在整个活动中强制执行。然而，代价是范围。如果只有一屏需要竖屏模式，应用该规则全局通常太过笨拙。
开启 iOS，支持的方向在Xcode中通过目标设置和应用元数据来设置。您可以定义应用支持的总体方向，然后在特定视图控制器中细化行为，当屏幕有更严格的要求时。
这种分离对于跨平台团队来说很重要。Native config回答，“这个应用通常应该允许什么？” Runtime code回答，“这个屏幕现在应该做什么？”
在Capacitor应用中进行编程控制
如果您使用Capacitor构建应用，动态控制通常应该放在code，靠近需要它的路由或视图。例如，登录屏幕可能更容易使用竖屏，而媒体屏幕或摄像头流可能需要根据设备如何握持来允许旋转。
一个插件可以使该逻辑可读并避免自定义本机管道。__CAPGO_KEEP_0__屏幕方向插件 Capacitor screen orientation plugin for Capacitor apps 让您读取当前方向，应用一个限制，例如竖屏模式，并在用户返回到一个灵活屏幕时移除该限制。
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 决策，技术决策是第二位的。 code 通常是简单的。 硬部分是选择感觉自然的行为。
一个简短的检查清单有助于：
- 为主要上下文进行设计： 如果大多数用户从直立开始，设定横向为界面最强大的版本。
- 支持一个更广泛的显示模式，仅在它有价值时： 不要阻止旋转在那些从额外宽度中受益的屏幕上。
- 只有在有明确原因时才锁定： 一个表单、结帐或安全流程可能会为此辩护。 内容屏幕通常不会。
- 在旋转时保留状态： 用户不应丢失输入、滚动位置或选定的选项卡。
- 测试两种屏幕方向在真实设备上： 模拟器会错过不适合的转换、键盘重叠和安全区域问题。
对于更广泛的布局决策， cross-platform UI and UX guidance for Capacitor apps 适合与屏幕方向测试一起使用，因为同一屏幕在不同设备大小和平台约定下往往需要感觉像本地应用一样。
主要的收获很简单。如果你问的是什么是竖屏方向，答案不是仅仅是“垂直”。它是一种框架规则、一种布局状态和用户期望。好的应用会对待它那样。
If you’re shipping Capacitor apps and need controlled orientation behavior alongside fast post-release fixes, Capgo 值得一看。它为CapacitorJS和Electron应用提供实时更新，并且也维护了屏幕方向等应用功能的插件，例如锁定或启用特定视图而不需要重建整个发布流程。
