文档查看器即使在技术上功能完整，也可能在狭窄的屏幕上让人感觉难以使用。密集的工具栏、微小的控件、过大的侧面面板以及固定尺寸的容器会迅速把一个简单的预览变成令人沮丧的体验。
对于基于 Windows 的 ASP.NET 和 .NET 应用程序，Doconut 提供了一个嵌入式文档查看 SDK，支持业务文档、PDF 文件、CAD 图纸、电子邮件文件和图像。你的应用仍然负责周围的布局、身份验证、授权、存储以及文档工作流。
本指南聚焦于这些外围体验：如何为嵌入式查看器提供足够的空间、让应用控件使用舒适、处理方向变化，并在不依赖未经验证的 SDK 源代码的情况下测试真实文档。
响应式设计始于查看器之外
查看器只能使用其父布局提供的空间。如果应用将其放在狭窄的卡片中、给它固定的桌面宽度，或用多个持久面板环绕，它的文档区域将始终显得拥挤。
从以下三个问题开始：
- 此页面的主要任务是什么？
- 阅读时哪些应用控件必须保持可见？
- 哪些次要面板可以折叠或隐藏在按钮后面？
对于专用的文档页面，查看器通常应是主导元素。元数据、评论、审批和工作流操作可以保持可用，而不占用文档的永久空间。
根据可用空间规划布局
响应式行为应依据组件可用的空间，而不是对特定设备名称的假设。
宽布局
在宽视口下，页面可能显示：
- 文档缩略图或导航面板
- 主文档画布
- 用于评论或元数据的次要工作流面板
- 完整的应用操作集合
当次要面板变为抽屉时，需要添加对话框行为、焦点管理以及你的设计系统要求的可访问标签。
让应用控件触控友好
查看器周围的控件应在无需精确指针移动的情况下易于激活。
实用指南包括：
- 为交互控件提供约 44 × 44 CSS 像素 的目标区域。
- 在破坏性操作和常用操作之间留出足够的间距。
- 不要依赖悬停来显示关键信息。
- 为键盘用户保持焦点指示可见。
- 为仅图标按钮提供可访问名称。
- 避免将关键控件放置在浏览器或系统手势区域附近。
不要使用猜测的选择器或未文档化的 CSS 变量覆盖 Doconut 的内部样式。请使用已安装 SDK 版本的官方资源，并将响应式规则应用于应用拥有的容器和控件。
将侧面板视为可选工作区
缩略图、搜索结果、批注、元数据和工作流历史都很有价值，但它们不应同时与文档竞争。
在紧凑布局下：
- 仅在用户请求时打开侧面板。
- 关闭后将焦点返回到打开它的按钮。
- 在适当情况下将焦点限制在模态面板内部。
- 为面板提供明确的标题和关闭操作。
- 面板打开或关闭时保持文档的当前位置不变。
如果查看器提供了自己的面板，请在添加第二层应用级导航系统之前，先测试其文档化的响应式行为。
保持文档工作区快速
响应式设计不仅仅是视觉效果。大型文档会暴露内存、带宽和渲染限制，尤其是当页面还包含复杂仪表盘或动画时。
减少竞争工作
在用户阅读时暂停装饰性动画，避免在查看器周围使用高开销效果，并移除不必要的观察者或事件监听器。
预留布局空间
在加载前为查看器宿主提供稳定的高度。这可以防止大幅布局位移并降低用户误点错误控件的概率。
有意加载次要功能
评论、审计历史和大型元数据面板并不一定要随第一页面文档一起加载。应在用户打开相关面板时再延迟加载，以匹配你的工作流。
测试具代表性的文件
使用超长 PDF、宽表格、详细 CAD 图纸、大尺寸图像以及带有特殊字体的文档进行测试。小样本文件无法揭示生产环境的极限。
在服务器端保持访问控制
响应式呈现并不改变应用的安全职责。每一次文档请求仍需通过身份验证和文档特定的授权。
对于 ASP.NET Core 应用，标准机制如身份验证中间件、策略、声明、[Authorize] 特性以及基于资源的授权可以保护解析文档的服务器路由。
应用应当：
- 使用服务器生成的文档标识符。
- 验证当前用户是否有权访问请求的文档。
- 将存储凭据和不受限制的路径远离客户端。
- 对在查看器页面中显示的错误进行清理。
- 对原始文件和临时文件实施明确的保留规则。
- 避免记录文档内容、机密信息或敏感访问 URL。
隐藏下载、打印或右键菜单操作可能有助于预期的工作流，但它并不能替代服务器端授权，也无法阻止内容可见后所有形式的捕获。
将 Doconut 集成到响应式体验中
Doconut 提供嵌入式文档查看层，应用负责响应式外壳和业务工作流。
一个合理的实现顺序是：
- 确认所需的文件格式和查看器功能。
- 为你的 .NET 应用集成受支持的 Doconut 包。
- 使用服务器端授权保护文档解析。
- 将查看器放置在流式、由应用拥有的宿主容器中。
- 为应用工具栏和次要面板设计紧凑状态。
- 测试尺寸变化、方向切换、焦点、加载和错误行为。
- 使用接近生产的文档和并发会话验证结果。
请查阅已验证的 Doconut Viewer 产品页面 以获取当前产品信息。使用 官方下载和文档页面 获取针对特定版本的安装与集成说明，而不是复制第三方帖子中未文档化的 SDK 示例。
响应式查看器审查清单
布局
- 查看器获得页面中最大的可用空间。
- 固定宽度不应导致水平滚动。
- 次要面板能够平滑折叠。
- 当视口高度受限时布局仍保持可用。
- 加载和错误状态预留适当空间。
交互
- 应用控件拥有舒适的目标尺寸。
- 关键操作不依赖悬停。
- 仅图标控件具备可访问名称。
- 焦点保持可见并遵循逻辑顺序。
- 抽屉和对话框能够正确返回焦点。
文档
- 大型 PDF 仍可顺畅导航。
- 宽表格可在不破坏页面布局的情况下检查。
- 详细图纸保留可用的缩放和平移空间。
- 长文件名和错误信息不会溢出。
- 改变布局尺寸不会不必要地重新加载文档。
安全与运维
- 服务器对每一次文档请求进行授权。
- 存储细节保持私密。
- 文件和临时数据的保留策略已文档化。
- 错误和日志不包含敏感信息。
- 已测试资源限制和并发会话行为。
常见问题
应用是否应为手机和桌面维护独立的查看器页面？
通常不需要。单一的响应式页面更易维护。根据可用空间调整布局，并逐步展示次要控件。
应用可以覆盖查看器的内部 CSS 吗？
避免使用未文档化的选择器和变量。仅对宿主容器和自己的应用控件进行样式修改。仅使用针对所部署 Doconut 版本的官方自定义点。
在紧凑布局下是否应隐藏下载和打印按钮？
这属于产品决策而非安全边界。如果操作被允许但空间不足，可将其放入可访问的溢出菜单；如果不被允许，则在服务器端强制该策略。
应如何测试大型文档？
构建一个已脱敏的测试集合，反映实际的页数、文件大小、字体、图纸和表格。每当 SDK、.NET、Windows Server 或布局发生变化时，重复执行该套测试。
结论
强大的移动文档体验始于流式容器、文档优先的布局、舒适的控件、可选的侧面板、可预测的尺寸变化以及服务器端授权。
Doconut 能为你的 Windows .NET 应用提供查看能力。你的团队随后可以专注于响应式应用外壳、安全规则和工作流，使查看器自然融入产品。