请记住，这是经典的asp

更好的是，Response.Write语句中包含所有HTML或者通过<％=％>将变量插入HTML。
例如

Response.Write "<table>" & vbCrlf
Response.Write "<tr>" &vbCrLf
Response.Write "<td class=""someClass"">" & someVariable & "</td>" & vbCrLf
Response.Write "</tr>" & vbCrLf
Response.Write "</table>" & vbCrLf

VS

<table>
  <tr>
     <td class="someClass"><%= someVariable %></td>
  </tr>
</table>

我主要是从性能角度询问，如果要插入多个变量，对服务器的影响最小？

如果没有技术上的差异，那么一个论据又是另一个论据是什么？

解决方案

从个人偏爱的角度来看，我更喜欢<％=％>方法，因为我认为它提供了更好的静态内容分离变量内容。

<％=％>，其余的扩展为Response.Write()，所以最后还是一样。

切换到Response.Write并不会提高性能，并且使用快捷方式表示法可以更快地读取和维护。

我们应该从代码重用和代码可维护性(也称为可读性)的角度来构想此问题。无论哪种方式，实际上都没有性能提升。

响应格式将呈现HTML，如下所示：

<table>
<tr>
<td class="someClass">variable value</td>
</tr>
</table>

结果，不仅产生代码的方法不可读，而且结果也被不适当地加以制表。坚持使用其他选项。

首先，我们应该考虑的最重要因素是易于维护。我们可以用金钱和时间来购买服务器场，否则我们将不得不破译一个杂乱的网站进行维护，从而浪费时间和金钱。

无论如何，都没关系。归根结底，ASP所要做的只是执行一个脚本！ ASP解析器获取该页面，然后将<％= expression％>转换为直接脚本调用，并且HTML的每个连续块都成为对Response.Write的一个大调用。除非页面在磁盘上发生更改，否则所生成的脚本将被缓存并重新使用，这将导致重新计算缓存的脚本。

现在，过多使用<％=％>导致了现代版本的"意大利面条代码"：可怕的"标签汤"。我们将无法做出逻辑的正面或者反面。另一方面，过多使用Response.Write意味着我们将永远无法看到页面，直到它呈现为止。适当时使用<％=％>以获得两全其美。

我的第一个规则是要注意"可变文本"与"静态文本"的比例。

如果只有几个地方要替换可变文本，则<<％=％>语法非常紧凑且可读。但是，随着<％=％>的积累，它们使越来越多的HTML变得晦涩难懂，同时HTML也使越来越多的逻辑变得晦涩难懂。通常，一旦开始执行循环，就需要停止并切换到Response.Write。

没有很多其他的硬性规定。我们需要为特定页面(页面的一部分)决定哪一个页面更重要，或者自然地更难理解，或者更容易被破坏：逻辑还是HTML？通常是一个或者另一个(我已经看过数百种情况)

如果逻辑更为关键，则应将更多的精力放在" Response.Write"上；它将使逻辑脱颖而出。如果HTML更为严格，则支持<％=％>，这将使页面结构更加可见。

有时，我不得不同时编写两个版本并进行比较以决定哪个版本更具可读性。这是万不得已的方法，但是请在我们脑海中浮现代码的情况下执行此操作，三个月后当我们必须进行更改时，我们会感到很高兴。

<％= Bazify()％>在从包含某些HTML的内联短表达式生成HTML时很有用。

当我们需要使用大量代码内联一些HTML时，Response.Write" foo"会更好。

从技术上讲，它们是相同的。

不过，说到示例，Response.Write代码使用＆进行了很多字符串连接，这在VBScript中非常慢。而且，就像罗素·迈尔斯(Russell Myers)所说的那样，它的制表符与其他代码的制表符不同，这可能是无意的。

在大多数情况下，出于某些原因，我更喜欢<％=％>方法。

• HTML向IDE公开，因此可以对其进行处理，为我们提供工具提示，标签关闭等。
• 维护输出HTML中的缩进更加容易，这对于重新设计布局非常有帮助。
• 没有在所有内容上添加vbCrLf的新行，并且再次用于检查输出源。

我更喜欢<％=％>，仅是因为它使Java开发更加容易。我们可以编写引用控件的代码，如下所示

var myControl = document.getElementById('<%= myControl.ClientID %>');

然后，我可以在JavaScript代码中以任何方式使用该控件，而不必担心硬编码ID。

Response.Write在某些情况下可能会破坏一些ASP.NET AJAX代码，因此，我尝试避免使用它，除非使用它在自定义控件中呈现特定内容。

除了其他人已经解决的代码可读性/可维护性问题之外，问题特别是关于当我们要插入多个变量时的性能，因此我假设我们将多次重复执行类似代码片段的操作。在这种情况下，我们应该通过使用单个Response.Write而不将所有换行符串联来获得最佳性能：

Response.Write "<table><tr><td class=""someClass"">" & someVar & "</td></tr></table>"

浏览器不需要换行符或者选项卡或者任何其他漂亮的格式来解析HTML。如果要提高性能，可以删除所有这些。我们还将使HTML输出变小，这将使我们更快地加载页面。

在单个变量的情况下，并没有太大的区别。但是对于多个变量，我们希望最大程度地减少HTML和ASP之间的上下文切换，每次跳转到另一个跳转都会受到打击。

为了帮助在构建较长的语句时提高可读性，可以在源代码中使用VBScript行连续字符和制表符(但不能在输出中使用制表符)来表示结构，而不会影响性能：

Response.Write "<table>" _
        & "<tr>" _
            & "<td class=""someClass"">" & someVar & "</td>" _
        & "</tr>" _
        & "<tr>" _
            & "<td class=""anotherClass"">" & anotherVar & "</td>" _
        & "</tr>" _
        & "<tr>" _
            & "<td class=""etc"">" & andSoOn & "</td>" _
        & "</tr>" _
    & "</table>"

它不像HTML版本那样清晰易懂，但是如果我们将大量变量放入输出中(即在HTML和ASP之间进行大量上下文切换)，则会看到更好的性能。

性能提升是值得的还是扩展硬件是否会更好是一个单独的问题，当然，这并非总是一个选择。

更新：有关通过Response.Buffer提高性能和避免上下文切换的信息，请参见Len Cardinal的MSDN文章中的提示14和15：http://msdn.microsoft.com/zh-cn/library/ms972335.aspx#asptips_topic15.

我在执行ASP / PHP时尝试使用MVC范例。它使事情最容易维护，重新架构，扩展。在这方面，我倾向于拥有一个代表模型的页面。它主要是VB / PHP，并设置vars供以后在视图中使用。当循环以供以后包含在视图中时，它还会生成HTML块。然后，我有一个页面代表该视图。大多数情况下，HTML都带有<％=％>标签。该模型在视图中为#include -d，然后我们便离开了。控制器逻辑通常是在JavaScript的第三页或者服务器端完成的。

此处的许多答案表明，两种方法产生的输出相同，并且选择是编码风格和性能之一。似乎相信<％％>之外的静态内容将成为单个Response.Write。

但是，更确切地说<％％>之外的代码是通过BinaryWrite发送的。

Response.Write接受一个Unicode字符串，并将其编码为当前的Response.CodePage，然后再将其放入缓冲区。对于ASP文件中的静态内容，不会进行这种编码。 <％％>之外的字符逐字逐字地转储到缓冲区中。

因此，如果Response.CodePage与用于保存ASP文件的CodePage不同，则两种方法的结果可能会有所不同。

例如，假设我将这些内容保存在标准的1252代码页中：-

<%
     Response.CodePage = 65001
     Response.CharSet = "UTF-8"
 %>
<p> The British ￡</p>
<%Response.Write("<p> The British ￡</p>")%>

第一段是乱码，因为不会使用UTF-8编码发送该段，所以第二段很好，因为提供的Unicode字符串已编码为UTF-8.

因此，从性能的角度来看，最好使用静态内容，因为它不需要编码，但是如果保存的代码页与输出代码页不同，则需要小心。因此，我更喜欢另存为UTF-8，包括<％@ codepage = 65001并设置Response.Charset =" UTF-8"。

我同意Jason的观点，现在更是如此，因为.NET提供了MVC框架来替代.NET最初的糟糕Web Form / Postback / ViewState。

也许是因为我是老式的经典ASP / HTML / JavaScript而不是VB桌面应用程序程序员，这使我不明白" Web表单的方式"吗？但令我感到高兴的是，我们似乎已经走了一大圈，回到了Jason所指的方法论上。

考虑到这一点，我将始终选择一个包含页面，该页面在有效的模板HTML"视图"中包含模型/逻辑和<％=％>标记。HTML将更具"可读性"，并且逻辑将与传统ASP所允许的尽可能多地分开；你用那块石头杀死了几只鸟。

我的经典ASP生锈，但是：

Response.Write "<table>" & vbCrlf
Response.Write "<tr>" &vbCrLf
Response.Write "<tdclass=""someClass"">" & someVariable & "</td>" & vbCrLf 
Response.Write "</tr>" & vbCrLf 
Response.Write "</table>" & vbCrLf

这是按原样运行的。但是，这是：

<table>
  <tr>
     <td class="someClass"><%= someVariable %></td>
  </tr>
</table>

结果是：

Response.Write"<table>\r\n<tr>\r\n<td class="someClass">"
Response.Write someVariable
Response.Write "</td>\r\n</tr>\r\n</table>"

其中\ r \ n是vbCrLf

因此，从技术上讲，第二个更快。但是，差异将以毫秒为单位进行度量，因此我不必担心。我会更担心的是，上一个几乎是无法维护的(特别是HTML-UI开发人员)，而第二个则很难维护。

@Euro Micelli维护的道具是关键(这也是为什么Ruby，Python等语言(过去还是……)的原因)Cand Java超越了C，C ++和Assemblyhuman可以维护代码，这就是方法比节省页面加载时间几毫秒更为重要。

当然，C / C ++等也有自己的位置。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。 :)