DeepL翻译是否支持原文与译文对照显示功能，具体应如何开启并设置？
DeepL 网页版与桌面客户端默认左右分栏对照原文译文，本文给出各平台最短开启路径、移动端差异与文档翻译替代方案。
如果你在搜索“DeepL 翻译是否支持原文与译文对照显示”，多半是因为手头有一份需要逐句核对的材料——合同条款、技术文档、对外稿件——单独看译文不放心，必须把原文与译文放在一起核对。先说结论：截至当前的最新版本，DeepL 的网页版翻译器与桌面客户端在默认状态下就是把原文和译文放在同一屏的两块区域里；所谓“对照显示”并不是一个需要单独勾选的开关，而是随平台与窗口尺寸变化的一套布局。本文不打算给你一个不存在的按钮，而是把三件事讲清楚：在哪里能看到对照、看不到时怎么补，以及什么时候不该硬要对照。
结论先行：对照显示在 DeepL 里是“布局”，不是“设置项”
很多用户的直觉是：既然有“双栏查看”的需求，软件里就应该有一个叫“对照显示”或“双栏模式”的开关。实际体验下来并非如此。DeepL 翻译器的交互模型是“左侧输入、右侧输出”，原文区与译文区从一开始就并存；你不需要开启什么，只需要保证屏幕宽度足够让两块区域并排显示。换句话说，你遇到的“看不见对照”，通常不是功能被关掉了，而是窗口太窄、设备形态不同，或者你用的是文档翻译而非文本翻译。
把这一点想明白，后面的操作就顺了。真正需要你动手调整的，是三类东西：屏幕宽度（决定并排还是堆叠）、翻译载体（文本模式还是文档模式），以及你是否使用 Pro 权限下的可编辑译文与术语表。它们共同决定“对照”的质量，而不是某个隐藏的复选框。
需要提醒的是：DeepL 的界面文案、按钮位置与可用功能会随版本迭代变化。本文描述的路径基于撰写时可公开查证的客户端形态；若你的界面与文中略有出入，请以实际安装版本为准，不要为了“对上步骤”去猜测不存在的菜单。
功能拆解：DeepL 里的“对照”其实有五种形态
同样是“看原文、看译文”，在不同入口下的呈现方式差别很大。把它们分开看，才能判断自己缺的是哪一种。
形态一：网页版翻译器的同屏分栏
打开浏览器访问 DeepL 翻译器页面，默认就是左原文、右译文，这是最标准、也最接近“双栏查看”的形态。它的好处是双向可编辑：你不仅能在左侧改原文，也能直接在右侧的译文框里修改措辞，改完可以整段复制走。对做本地化校对的人来说，这个“可直接改译文”的细节比任何对照开关都实用——不必导出到第三个工具里再改。
边界也很清楚：当浏览器窗口收窄到一定程度，两块区域会自动改为上下堆叠，这时看到的是“原文在上、译文在下”，需要滚动才能对照。这不是故障，而是响应式布局的正常行为。
形态二：桌面客户端的翻译窗口
Windows 与 macOS 的 DeepL 桌面客户端提供独立的翻译窗口，原文输入区与译文输出区在同一窗口内相邻排布。经验性观察是：窗口越宽，越容易呈现清晰的并列关系；窗口拉窄或切换到小尺寸窗口模式时，排布会随之变化。由于不同版本对窗口最小宽度的处理不完全一致，建议在自己机器上做一次简单验证——把窗口从最大化逐步拖窄，观察两块区域从并排变为堆叠的临界点，并记住这个宽度；之后校对时把窗口保持在临界点之上即可。
桌面客户端的额外价值在于跨应用取词。部分版本支持在任意应用里复制文本后快速唤起翻译，具体触发方式以所在版本的设置界面为准。如果这条路径在你的版本里不可用，也不影响主窗口的对照使用，不必为此折腾。
形态三：移动端的上下堆叠
iOS 与 Android 客户端受屏幕尺寸限制，基本采用“输入在上、译文在下”的纵向结构，原文与译文不会真正并排。严格来说，移动端没有桌面意义上的对照显示。如果必须在手机上完成逐句核对，可用的补偿手段有三种：把手机横屏，部分界面会因此获得更大的单屏信息量；把原文复制到备忘录，与译文分屏（需系统支持分屏或悬浮窗）；或者干脆把这一步留到电脑上做。
小场景：一位做跨境电商的运营，常在通勤路上用手机处理供应商发来的英文邮件。她的做法是先在手机上拿到译文，快速判断“要不要现在回”，把需要逐字推敲的邮件标记出来，回到工位再用桌面端并排核对后回复。把“看懂”和“核对”拆成两个场景，比在手机上硬凑双栏更省时间。
形态四：浏览器扩展的即时浮层
浏览器扩展的逻辑与翻译器不同：它不提供长期驻留的双栏界面，而是在选中网页文字后弹出浮层显示译文。原文就在网页上，译文在浮层里，两者视觉上确实同时可见，但它只适合短句、短语的即时确认。对于需要成段比对的内容，浮层会遮挡原文，反而不如直接开一个翻译器标签页。
形态五：文档翻译的“文件级”产出
这是最容易被误解的一环。文档翻译的产出是一份独立的译文文件，界面上通常看到的是上传、进度与下载入口，而不是逐段并排的原文与译文。因此，如果目标是“逐句核对”，文档翻译并不是对照显示的载体。可行的替代方案是：把文档按章节拆成若干段，用文本模式逐段翻译并对照；或者先用文档翻译拿到整体译文，再用办公软件自带的多窗口/并排查看功能做二次比对。后者牺牲了一一对应的精确度，但胜在快。
网页版最短操作路径（含设置项说明）
如果只是想尽快看到并排的原文与译文，按下面的顺序走一遍即可，全程不需要找“对照”这个词。
- 在桌面浏览器中打开 DeepL 翻译器首页，确认处于“文本”标签而非“文档”标签。
- 在左上角的源语言选择器中确认语言。若不确定原文语种，保留“自动检测”即可；如果已知语种，手动指定会更稳，避免短句被误判。
- 在右上角选择目标语言。
- 把原文粘贴或输入到左侧区域，译文会在右侧区域自动生成。
- 若窗口较窄导致两块区域堆叠，把浏览器窗口拉宽，或按 F11 进入全屏，通常即可恢复并排。
关于“设置”，网页版真正会影响对照体验的选项并不多，但有几个值得知道。第一是译文的可编辑性：右侧译文框可以直接点击修改，改完再复制，这个动作不改变原文，适合做术语统一。第二是部分目标语言支持正式/非正式语气的切换，可用语种与是否对免费用户开放，以界面实际显示为准。第三是术语表（Glossary），属于 Pro 能力，开启后可以强制某些词按指定译法输出——对需要反复核对同一批术语的人来说，这比手动改十遍更可靠。
还有一个小细节常被忽略：点击译文中的某个词，界面上可能出现该词的其他译法提示。这个交互对单句校对很有用，但属于“词语级参考”，不能替代整段语义判断，别把它当成权威依据。
桌面客户端的最短路径与平台差异
Windows 与 macOS 的操作逻辑基本一致：安装并启动客户端，登录账号（免费账号同样可以登录，Pro 账号会额外解锁文档、术语表等能力），在翻译窗口中输入或粘贴原文，译文出现在相邻区域。两平台的差异主要体现在快捷键与窗口管理习惯上——macOS 用 Command 组合键，Windows 用 Ctrl 组合键；这是系统层面的差异，与 DeepL 本身无关。
值得强调的是窗口尺寸对对照效果的影响。经验性观察是：显示器分辨率 1920×1080 及以上、客户端窗口占用超过屏幕宽度一半时，并排阅读的舒适度明显更好；在 1366×768 这类小屏笔记本上，窗口最大化往往仍嫌局促，此时可以临时隐藏系统任务栏或关闭侧边栏，把横向空间让给翻译窗口。
例外与取舍：什么时候“对照”反而拖慢你
对照显示听起来只有好处，实际工作中却有两类明确的成本，值得提前判断。
其一是阅读效率。并排布局意味着每块区域的可用宽度减半，长句在窄栏里会频繁折行，眼睛需要在左右之间反复跳跃。如果只是想知道一段外文“大概说了什么”，逐句对照反而是负担；直接读译文，遇到关键句再回头看原文，速度要快得多。把对照留给需要担责的内容——合同、对外文案、技术参数——是更经济的用法。
其二是信息暴露面。对照意味着原文和译文会同时停留在屏幕上。在开放办公区或共享屏幕场景下，若原文包含敏感信息，并排布局会把内容摊得更大、更显眼。这不是 DeepL 的问题，而是使用姿势的问题：这类场景更适合用浏览器扩展的浮层逐句看，或者干脆在私密环境下处理。
还有一类边界值得写进团队规范：不要把“并排看着没问题”当成质量结论。机器翻译的错漏往往表现为语义偏移而非语法错误，一眼扫过去很通顺，恰恰是最容易漏检的情况。经验性建议是抽取关键句做回译验证（把译文再翻回原文语言，看是否与原文一致），这比单纯并排对视更能发现问题。
第三方集成下的对照实现：以 API 为例
如果团队把 DeepL 作为接口嵌进内部系统，“对照显示”这件事就完全由你们自己的前端决定。DeepL 的接口返回的是译文文本，不包含界面。想做出双栏效果，做法是：前端保留原文输入值，把接口返回的译文渲染到相邻容器，两者用同一个滚动容器或联动滚动绑定。这里没有官方现成的“对照组件”，也不存在可以直接调用的开关参数。
在权限设计上，建议遵循最小化原则：为翻译功能单独申请密钥，不要复用其他系统的凭证；把调用额度与业务模块绑定，便于从用量上定位异常；日志里避免完整落盘原文与译文，尤其是涉及个人信息或商业条款的内容。这三条不是 DeepL 的强制要求，而是把外部服务接进内部流程时的通行做法。
这段伪代码的重点只有一句：原文不要在用完之后丢掉。很多自建工具之所以“只有译文没有对照”，根源就是在请求发出后把源文本清空了，想补也补不回来。
故障排查：对照看不到时的四种典型情况
对照看不到时，先按现象归类，再逐项验证，通常比反复重装更有效。下表把常见现象、可能原因、验证方法和处置方式放在一起，便于快速定位。
| 现象 | 可能原因 | 验证方法 | 处置 |
|---|---|---|---|
| 译文区不出现，只有原文 | 源语言与目标语言被设成同一种；或输入被判定为无需翻译 | 检查两个语言选择器是否相同；换一段明显不同语种的文本再试 | 修正语言对；确认目标语言不是“自动检测” |
| 两块区域变成上下堆叠 | 窗口或屏幕宽度不足，触发响应式布局 | 逐步拉宽窗口，观察何时恢复并排 | 最大化窗口、全屏浏览，或换用桌面客户端 |
| 上传文档后只看到下载入口 | 文档翻译本身产出独立文件，不提供逐段对照 | 改用文本模式粘贴同一段落，观察是否出现并排布局 | 拆分段落走文本模式，或用办公软件做二次比对 |
| 移动端始终没有并排视图 | 手机屏幕宽度不足以容纳双栏，属于设计预期 | 横屏后观察布局是否变化 | 改用平板或桌面端完成核对环节 |
排查时有个通用原则：先区分“是布局问题还是功能问题”。布局问题改窗口就能解决，功能问题则要回到语言选择、账号权限、网络状态这些变量上。多数“看不到对照”的反馈，最终都落在第一类。
适用与不适用：一张判断清单
把下面两组条件对照一下，基本能判断该不该花时间追求并排对照。
适合并排对照的场景：合同与法务条款的逐条核对；对外发布文案的终稿审校；技术文档中参数、单位、型号的交叉检查；需要把同一批术语在多个段落间保持一致的本地化项目；以及任何“翻错了要有人负责”的产出。
不太需要的场景：快速了解一封邮件的大意；浏览外文资讯判断是否值得深读；单句即时查询；以及原文本身结构混乱、逐句对应意义不大的口语化内容。在这些场景里，并排反而增加视觉负担。
还有一条容易被忽略的准入条件：如果原文属于高度敏感类别，先确认所在组织对“把文本发送到外部翻译服务”是否有明确规定，再谈布局。合规判断的优先级高于效率优化，这一点没有例外。
最佳实践：一份可直接照做的检查表
把前面的内容压缩成可执行的决策规则，按顺序过一遍即可。
- 先定载体。需要逐句核对，用文本模式；只需要整体译文，用文档模式。不要指望文档模式给你逐段对照。
- 再定设备。核对环节放在桌面端或网页版宽屏下完成，手机只承担“看懂大意”的任务。
- 锁定语言对。已知语种时手动指定源语言，减少自动检测在短句上的误判。
- 统一术语。批量项目提前准备术语表（Pro 能力），比事后逐条手改更省事。
- 保留原文。自建工具时，请求发出后不要清空源文本，否则对照无从谈起。
- 抽样回译。关键段落做一次回译验证，作为对照阅读的补充而非替代。
- 控制暴露面。敏感内容避免在共享屏幕或开放工位做并排展示。
这七条的顺序本身就有含义：先解决“在哪里翻”，再解决“用什么看”，最后才是术语与复核。若把顺序倒过来，很容易在手机上反复折腾布局，却忽略了真正影响质量的术语一致性和回译验证。
验证与观测：怎么确认你的对照确实生效
与其凭感觉判断“好像能对照”，不如做一次可复现的小验证。准备一段包含专有名词和数字的英文段落（例如产品规格描述），按以下步骤操作：先在桌面浏览器全屏打开翻译器，粘贴原文，确认译文出现在右侧同一水平线上；再把窗口宽度逐步收窄，记录两块区域从并排变为堆叠的大致宽度；接着在同一台机器上用桌面客户端重复一次，对比两者的堆叠临界点。最后把译文中的数字与原文逐个比对，确认没有单位或数量上的偏移。
这个验证过程大约几分钟，产出的是两条对你有用的经验值：你自己设备上的舒适窗口宽度，以及机器翻译在数字与专有名词上的稳定程度。前者决定日常怎么摆窗口，后者决定还需要人工复核哪些内容。
写在最后：把“对照”当成方法，而不是功能
回到最初的问题：DeepL 翻译是否支持原文与译文对照显示？答案是支持，但它的支持方式是把对照做进了默认布局里，而不是给你一个开关。网页版和桌面客户端在足够宽的窗口下天然并排，移动端受物理尺寸限制只能堆叠，文档翻译产出的是独立文件而非逐段对照。真正决定体验好坏的，是窗口宽度、翻译载体和设备选择这三件事，而不是某个藏在设置里的选项。
下一步建议这样动手：先打开桌面浏览器，全屏进入翻译器，粘贴一段手头真实要处理的内容，确认并排布局是否符合预期；如果不符合，按本文的排查表定位是布局问题还是语言设置问题；确认可用之后，再决定是否把这项工作迁移到桌面客户端或引入术语表。整个过程不需要安装额外插件，也不需要修改任何系统设置。经验性观察是，界面细节可能继续调整，但“先看布局、再看设置”的判断方法不会过时。