在现代Salesforce世界中驾驭Visualforce的定位与挑战

二月 06, 2026

作为一名Salesforce开发者，在LWC和Aura组件模型日益普及的今天，我曾多次以为Visualforce将彻底淡出我的日常工作。然而，现实却总是在不经意间提醒我，它仍然有其不可替代的定位。这篇文章就想聊聊我在实际项目中，如何重新认识并驾驭Visualforce，尤其是在那些“不得不”使用它的场景中，我所面临的问题、做出的判断和取舍。

为什么是Visualforce？老技术的新战场

通常来说，当我需要构建一个新的UI界面时，LWC是我的首选。它的组件化、现代化工具链和Lightning Experience原生体验都让我爱不释手。但有些时候，项目需求会把我“拽回”Visualforce的怀抱。其中最常见的，也是让我屡次与Visualforce打交道的场景，就是**复杂且像素级精确的PDF文档生成**。

PDF生成：Visualforce的“护城河”

我曾接到一个需求：为客户生成一份高度定制化的合同文档，要求页眉页脚、公司Logo、数据表格、动态文本等元素都必须严格按照设计稿呈现，而且需要支持分页、字体嵌入等高级特性。

LWC/Aura的局限： 当时我首先考虑的是LWC。但LWC主要在客户端渲染，要实现服务端PDF生成，通常需要借助第三方库（比如jsPDF），或者通过将LWC渲染的HTML传给一个Apex方法，再用PDF渲染库在服务器端处理。这些方案要么在客户端性能和功能上有限制，要么在服务端增加了额外的复杂性和依赖。更关键的是，要实现像Visualforce `renderAs="pdf"` 那样稳定且样式控制力强的服务端渲染，LWC并非最佳选择。
Visualforce的优势： Visualforce的renderAs="pdf"属性，虽然背后依赖的渲染引擎比较老旧，但它直接在Salesforce服务器上将页面内容转换为PDF，对于这种特定场景，其稳定性和可控性依然是LWC难以比拟的。尤其是在处理复杂表格、分页以及强制插入页眉页脚方面，Visualforce提供了更直接且经过验证的路径。

因此，尽管内心更倾向于现代技术栈，但为了完成任务，我最终还是回到了Visualforce。这个决定是基于对两种技术栈在特定场景下优劣的权衡，而非单纯的技术偏好。

View State：挥之不去的噩梦

决定使用Visualforce后，很快我就遇到了老生常谈的问题：View State限制。在合同生成场景中，我们需要从多个关联对象中抓取大量数据，包括主合同信息、多行明细、附件链接等。当这些数据被包装到Controller的属性中，并在页面上被引用时，View State很容易就超出135KB的限制，导致页面崩溃，提示“Maximum view state size limit exceeded”。

我的判断与解决方案：

问题根源： Visualforce在每次请求（无论POST还是GET）时都会将页面上的所有数据（包括Controller属性）打包成View State，随页面一同传输。这在需要大量数据的PDF生成场景中是致命的。

取舍与解决：使用transient关键字

最直接有效的方案是使用transient关键字。任何被transient标记的Controller属性都不会被序列化到View State中。

public class ContractPdfController {
    public Id contractId { get; set; }
    // 这部分数据只在当前请求中用于PDF渲染，不需要在后续请求中保持状态
    public transient Contract__c contractData { get; set; } 
    public transient List<ContractLineItem__c> lineItems { get; set; }

    public ContractPdfController() {
        contractId = ApexPages.currentPage().getParameters().get('id');
        if (contractId != null) {
            // 在构造函数或getter中重新查询数据
            contractData = [SELECT Id, Name, ... FROM Contract__c WHERE Id = :contractId];
            lineItems = [SELECT Id, ItemName, Quantity, Price FROM ContractLineItem__c WHERE Contract__c = :contractId];
        }
    }

    // 如果某些数据需要惰性加载，可以在getter中查询
    public List<Attachment> getAttachments() {
        if (attachments == null && contractId != null) {
            attachments = [SELECT Id, Name, BodyLength FROM Attachment WHERE ParentId = :contractId];
        }
        return attachments;
    }
    private transient List<Attachment> attachments; // 同样使用 transient
}

我之所以选择大量使用transient，是因为PDF生成是一个“单次性”的页面渲染过程。一旦PDF生成并下载，页面本身的交互状态就不再重要了。因此，我不需要让Salesforce保留页面上的所有数据状态，只需在每次加载时（或在生成PDF的特定操作中）重新获取一次数据即可。这大大减轻了View State的负担。

取舍与解决：仅传递ID，按需查询
另一个策略是，尽量不在页面和Controller之间传递完整的数据对象，而是只传递记录ID。例如，如果页面需要展示一个相关的账户信息，我只在Controller中保存账户ID，然后在getAccount()方法中惰性查询完整的Account对象。这样，View State中只包含一个轻量级的ID，而不是整个Account记录。

样式与布局：与`renderAs="pdf"`的搏斗

Visualforce页面本身看起来可能很朴素，但renderAs="pdf"属性更是加剧了样式兼容性问题。它使用的PDF渲染引擎对CSS的支持非常有限且老旧。

我的判断与解决方案：

问题根源： 许多现代CSS特性（如Flexbox、Grid布局、高级CSS选择器、Web字体等）在renderAs="pdf"中几乎不被支持。它更像是一个只理解基础CSS1和部分CSS2的浏览器。这意味着我无法使用惯用的响应式设计或现代UI框架。

取舍与解决：回归原始的HTML/CSS

为了实现精确的布局，我不得不放弃使用apex:pageBlock、apex:pageBlockTable等Visualforce标准组件。它们生成的HTML结构往往过于复杂，难以精准控制。我转向了更原始的HTML结构：大量的<div>、<table>（是的，CSS布局不行，表格布局又回来了）、以及内联样式或<style>标签中的嵌入式CSS。

<apex:page renderAs="pdf" applyHtmlTag="false" applyBodyTag="false" standardStylesheets="false" showHeader="false" sidebar="false" controller="ContractPdfController">
<html xmlns="http://www.w3.org/2099/xhtml" lang="en">
<head>
    <meta http-equiv="Content-Type" content="text/html;charset=UTF-8" />
    <style type="text/css" media="print">
        @page {
            size: A4;
            margin: 2cm;
            @top-center { content: element(header); }
            @bottom-center { content: element(footer); }
        }
        div.header { position: running(header); }
        div.footer { position: running(footer); }
        .page-break { page-break-before: always; }
        /* 更多的内联或嵌入式CSS，尽量使用简单的选择器和属性 */
        body { font-family: Arial, sans-serif; font-size: 10pt; }
        table { width: 100%; border-collapse: collapse; }
        th, td { border: 1px solid #ccc; padding: 5px; }
        /* ... 各种兼容性调整 */
    </style>
</head>
<body>
    <!-- 页眉 -->
    <div class="header">
        <img src="{!$Resource.CompanyLogo}" style="height: 50px;" />
        <h1>合同文件</h1>
        <hr/>
    </div>

    <!-- 页面主体内容 -->
    <p>合同编号: <b>{!contractData.Name}</b></p>
    <div class="page-break"></div> <!-- 强制分页 -->
    <h2>明细列表</h2>
    <table>
        <thead><tr><th>项目</th><th>数量</th><th>单价</th></tr></thead>
        <tbody>
            <apex:repeat value="{!lineItems}" var="item">
                <tr>
                    <td>{!item.ItemName}</td>
                    <td>{!item.Quantity}</td>
                    <td>{!item.Price}</td>
                </tr>
            </apex:repeat>
        </tbody>
    </table>
</body>
</html>

我特别注意了@page规则、page-break-before、page-break-after等属性，这些是控制PDF分页和页眉页脚的关键。为了让页面结构更“纯粹”，我还会将applyHtmlTag="false" applyBodyTag="false" standardStylesheets="false" showHeader="false" sidebar="false"这些属性设置为false，以避免Visualforce自动插入额外的HTML和CSS，给我更大的控制权。

图片处理： 对于Logo等图片，使用{!$Resource.StaticResourceName}引用静态资源是标准做法。但需要注意图片尺寸，过大的图片会增加View State（如果它被Controller引用）和PDF生成时间。

性能考量：优化PDF生成速度

即使解决了View State和样式问题，复杂PDF的生成速度也可能成为瓶颈。用户点击按钮后，等待几秒甚至十几秒才能下载PDF，这是不可接受的。

我的判断与解决方案：

问题根源： PDF生成是一个同步过程，尤其是在Apex Controller中进行大量数据查询和处理，会占用CPU时间。
取舍与解决：精简Controller逻辑
- 只查询所需数据： 避免SELECT *，只选择PDF中实际需要展示的字段。利用SOQL子查询减少查询次数。
- 数据处理前置： 如果有复杂的数据聚合或计算，尽量在PDF Controller的构造函数中完成，或者在getter方法中进行一次性处理，而不是在页面循环中反复计算。
- 减少页面逻辑： Visualforce页面上的apex:repeat或表达式求值，都会消耗性能。尽量在Apex Controller中预处理好列表，再在页面上简单渲染。
- 异步生成（特定场景）： 对于非常大的PDF，或者用户不需要立即下载的场景，可以考虑将PDF生成逻辑封装成一个Queueable或Batch Apex作业。用户点击按钮后，Job在后台运行，完成后通过邮件发送PDF或在Salesforce中作为附件保存。这涉及用户体验的取舍：立即响应 vs. 延迟但更稳定的生成。在我的合同场景中，用户通常需要立即下载，所以主要还是优化同步生成。

总结与展望

经过这一系列的折腾，我对Visualforce的看法变得更加 nuanced。它确实是一个老旧的技术，不再是构建现代化Salesforce UI的首选。然而，在某些特定的“利基市场”（Niche Market），比如我遇到的像素级精确的PDF生成、复杂且高度定制化的邮件模板（renderAs="html"），或者维护那些迁移成本极高的遗留系统时，Visualforce依然是工具箱中一个不可或缺的工具。

它考验的是开发者对底层HTML/CSS的理解，以及如何在资源受限的环境下做出权衡和优化。学会使用transient、理解View State的工作原理、掌握renderAs="pdf"的CSS限制并进行针对性开发，这些都是在与Visualforce打交道时宝贵的经验。

至于未来，我好奇Salesforce是否会推出更现代化的服务端PDF生成方案，或者LWC在未来能否直接支持类似renderAs="pdf"的功能，从而彻底取代Visualforce在这一领域的地位。在那之前，Visualforce仍然会默默地为一些关键的业务流程提供支撑。

Salesforce中文网