GridView AJAX化实战：告别Postback，实现无刷新分页与排序

简介：面向ASP.NET开发者的GridView实用示例包，针对VS自带的GridView在数据增删改操作上不灵活、页面刷新频繁、交互体验差等痛点，提供了一套基于ASP.NET 4.0与SQL Server 2008的轻量级解决方案，通过Ajax实现无刷新操作，可直接迁移到信息管理系统、后台管理模块或内部工具项目中。资源包共2个文件，包含一个htm格式的说明文档和一个rar格式的源码压缩包，整体仅1.52MB，结构紧凑、易于分发与部署。rar压缩包内的GridView示例代码逻辑清晰，完整覆盖新增、删除、修改等常用功能，htm说明文件对使用方式做了简明引介，帮助开发者在短时间内理解核心数据操作方法并快速整合到自有项目。示例可移植性强，无论是入门学习GridView与Ajax组合开发，还是在既有系统中查找表格无刷新操作的参考实现，都能从中获得直接可用的代码思路。目前已有650人浏览学习，值得作为常用开发素材收藏备用。

1. GridView 的假分页与真痛点：为什么它叫“好用”却不叫“顺手”

做过 ASP.NET WebForms 的人基本都跟 GridView 打过交道。数据表展示、分页、排序、行内编辑，拖一个控件绑定数据源就能跑，当年的开发效率确实没得挑。但它也是被吐槽最多的控件之一：每一次点页码、点表头排序、点“编辑”，都是一次整页刷新，浏览器白屏一下再重新渲染整张页面。产品经理站在背后看的时候，那种卡顿和闪烁实在没法解释“这是一个现代系统”。我碰到过不少同事直接放弃 GridView，转去用第三方表格组件，其实问题不在控件本身，而在你和 AJAX 效果之间还隔着一层没做好的封装。

这个标题里的“gridview（asp.net, ajax效果）”，本质上说的是一个非常经典的诉求：保留 GridView 的成熟交互，同时让用户感受不到整页回传。做法也不是什么黑科技，常见路线有三条：用 UpdatePanel 局部刷新、用 MVC/前后端分离重写表格、或者直接调用 WebMethod 丢 JSON 回来自己拼 HTML。这三条路线我都给不同项目用过，适用场景完全不同，本文会把每条路线的关键步骤、参数取舍和翻车点都展开讲。适合谁看？正在维护 WebForms 老系统、被分页刷新折磨的开发者，以及想给老项目做体验升级但又不想大动架构的人。本文不教你把 GridView 换掉，教你把手头这块 GridView 调成一个“点了不白屏”的表格。

2. 为什么 GridView 天生“闪屏”：从 Postback 到局部刷新的原理差

2.1 整页回传的根源：ASP.NET WebForms 的页面生命周期

GridView 的表头、行按钮、分页按钮，默认全部通过 Postback 触发服务器事件。所谓 Postback，就是把整个页面内容连同 ViewState 一起提交给服务器，IIS 上的 ASP.NET 运行时重新执行一遍 Page_Load，再执行当前控件的触发事件，最后把整个页面重新渲染回浏览器。这个过程有几个明显的性能问题：

第一，页面越大，回传的数据量越大。GridView 的 ViewState 默认把数据源的一部分序列化到隐藏字段里，几千行的数据表，光 ViewState 就能让请求体膨胀到上百 KB，甚至几 MB。第二，整个生命周期从头跑到尾，一个简单的翻页操作也会执行所有子控件的 Load、DataBinding，很多人在 Page_Load 里不管是不是回传都做一遍数据绑定，导致每次翻页都要重新查数据库查全表。第三，浏览器侧是整页重新渲染，页面一刷新，滚动条回到顶部，正在填的表单内容全没，体验自然差。

所以，当你说“给 GridView 加 AJAX 效果”，核心诉求其实是：把整页回传变成局部回传，让浏览器只更新表格那一片区域，不白屏、不丢滚动条、不重跑无关逻辑。这里说的 AJAX 并不是前端自己发 XMLHttpRequest，而是 ASP.NET 的异步回传机制，服务器端仍然走页面生命周期，但响应里只包含需要更新的区域内容。

2.2 UpdatePanel 到底做了什么：一个被低估的“局部渲染黑匣子”

UpdatePanel 是 ASP.NET AJAX Extensions 里的核心控件，作用就是把页面划分成若干独立区域。放到 UpdatePanel 里的控件触发回传时，ScriptManager 会拦截这次提交，改为异步回传：表单照常发到服务器，页面生命周期照常执行，但服务器只把 UpdatePanel 区域对应的 HTML 片段返回给浏览器，由客户端脚本替换掉原有内容。

这种方案有很明显的优点：事件模型完全不变，GridView 的分页、排序、编辑都是服务端事件，包进 UpdatePanel 后连一行业务逻辑都不用改。缺点同样明显：整个页面生命周期还在跑，后台代码依然全部执行，只是互联网上下行的数据变小了。用 F12 开发者工具看 Network 面板，你会发现请求不再是文档类型，响应里就是一小段 HTML。懂这个机制的人，可以靠一个 UpdatePanel 就把老项目的感官提速一个档次。

我一般会把 UpdatePanel 的机制和“前端 AJAX + 数据接口”的方案分成两档看待：如果项目本身就是 WebForms，后续也没有重构计划，用 UpdatePanel 是最短路径指望；如果项目已经部分改用前端框架，那 GridView 再省事也不值得迁就。这里给一张简单的方案选型表，取舍逻辑写清楚。

2.3 三种 AJAX 改造路线的对比与选型判断

之前给某公司维护过一个十年的老系统，表格全部是 GridView，每页 100 行、2000 行数据。分页一次，F12 看请求体积在 1.6 MB 左右，点一下要等 2 到 3 秒。第一轮改造我选择的是给所有 GridView 套 UpdatePanel，效果立竿见影：不再白屏，滚动条保住，带宽占用降了大半。但点分页那一瞬间还是会有半秒的顿挫，原因是服务器端依然全量绑定数据。

第二轮改造，我把其中一张数据量最大的表拆成 WebMethod 接口，前端用原生 JavaScript 发请求，返回的是拼好的 HTML 行。这下速度才真正起来了。结论其实很朴实：UpdatePanel 解决的是“刷新感”，接口方案解决的是“计算量”。表格数据量在千行以内、交互不频繁，UpdatePanel 足够；数据大、操作频繁，就必须把数据绑定和数据渲染压到最轻。本文后面的章节，会分别给出这两条路线的落地方案。

3. 最小改造方案：十分钟给 GridView 套上 UpdatePanel

3.1 页面结构改造：ScriptManager 与 UpdatePanel 的正确位置

WebForms 项目里要启用 UpdatePanel，第一个前提是页面上必须有且只有一个 ScriptManager。ScriptManager 可以放在任意位置，但习惯上是放在 form 标签内最顶部。UpdatePanel 放在页面下方，把 GridView 整体包进去。下面这段代码结构是最小可用方案，直接复制调整即可。

<asp:ScriptManager ID="ScriptManager1" runat="server" EnablePartialRendering="true" /> <asp:UpdatePanel ID="upGrid" runat="server" UpdateMode="Always"> <ContentTemplate> <asp:GridView ID="gvMain" runat="server" AutoGenerateColumns="False" DataKeyNames="Id" OnPageIndexChanging="gvMain_PageIndexChanging"> <Columns> <asp:BoundField DataField="Id" HeaderText="编号" /> <asp:BoundField DataField="Name" HeaderText="名称" /> <asp:BoundField DataField="CreateTime" HeaderText="创建时间" DataFormatString="{0:yyyy-MM-dd}" /> </Columns> </asp:GridView> </ContentTemplate> </asp:UpdatePanel>

这段代码的要点有三个。第一，ScriptManager 的 EnablePartialRendering 必须为 true，这是局部渲染的开关，保持默认 true 就行，但有些老项目会为了兼容某类第三方控件把它关掉，如果发现 UpdatePanel 不起作用，优先检查这个属性。第二，UpdatePanel 的 UpdateMode 设成 Always，表示页面上的任何异步回传都会更新它；如果你页面上有多个 UpdatePanel，建议按功能拆开，改成 Conditional，避免一次操作把所有区域全刷新一遍。第三，GridView 的 DataKeyNames 建议设置主键，后续做行内编辑、删除、取行数据都要通过它拿主键，不设置会给自己挖坑。

3.2 触发方式与刷新范围：UpdateMode 与 Triggers 控制边界

UpdateMode 有 Always 和 Conditional 两个值，理解它才不会被“整个页面都刷新”搞到头痛。Always 模式简单粗暴：页面上任何 UpdatePanel 内的控件触发异步回传，这个面板都会跟着刷新；Conditional 模式则只有面板内的控件触发回传、或者通过 Triggers 明确指定的控件触发回传时才会更新。一个常见的反面用法是：页面上放了两个 UpdatePanel，一个查列表，一个统计条数，设计意图是列表翻页时统计条数跟着变。如果用 Always，那另外某个区域触发的回传也会把列表和统计都刷一遍，浪费。正确的做法是两者都设 Conditional，然后在列表面板的 Triggers 里声明统计面板的刷新或者反过来。

<asp:UpdatePanel ID="upList" runat="server" UpdateMode="Conditional"> <ContentTemplate> <asp:GridView ID="gvList" runat="server" ... /> </ContentTemplate> <Triggers> <asp:AsyncPostBackTrigger ControlID="btnSearch" EventName="Click" /> </Triggers> </asp:UpdatePanel> <asp:UpdatePanel ID="upStat" runat="server" UpdateMode="Conditional"> <ContentTemplate> <asp:Label ID="lblTotal" runat="server" /> </ContentTemplate> </asp:UpdatePanel>

触发器里的 ControlID 指向的是 UpdatePanel 外部控件时才有意义，比如搜索按钮放在面板外面，点击后希望表格刷新。这个按钮必须声明为异步触发器，否则点击它仍然会走整页回传，UpdatePanel 哪怕写在页面里也不会生效。新手最容易犯的错就在这：按钮放在 UpdatePanel 外面，忘了加 Trigger，点按钮页面闪一下，还以为是 AJAX 没引入成功。

3.3 异步回传的 Loading 提示：用 PageRequestManager 减少焦虑感

局部刷新虽然不白屏，但从点击到表格更新之间还是有一段网络时间，这个时间里 UI 没有任何反馈，用户会觉得“卡死了”。常见做法是挂一个半透明遮罩加一个“加载中”图标。ASPNET 的 UpdatePanel 本身不带加载动画，需要用 PageRequestManager 这个客户端对象来拦截异步回传的开始和结束。

下面这段 JavaScript 放到页面底部，基于 ScriptManager 自动生成的客户端框架，注册 beginRequest 和 endRequest 两个阶段。beginRequest 触发时给表格上方显示一个 loading 层，endRequest 触发时隐藏。

Sys.Application.add_load(function () { var prm = Sys.WebForms.PageRequestManager.getInstance(); prm.add_beginRequest(function (sender, args) { var loading = document.getElementById("loadingMask"); if (loading) { loading.style.display = "block"; } }); prm.add_endRequest(function (sender, args) { var loading = document.getElementById("loadingMask"); if (loading) { loading.style.display = "none"; } }); });

需要配套在页面上放一个默认隐藏的 loading 节点，例如一个 div 盖在 GridView 上方。这里有个细节：endRequest 有个参数 args，如果异步回传过程中发生了未处理的异常，args.get_error() 会返回错误对象，可以在 endRequest 里检查并提示，避免页面静默失败。另外，如果面板里有比较重的服务器逻辑，建议配合 UpdateProgress 控件，它不需要写 JavaScript，前端放一个 UpdateProgress，AssociatedUpdatePanelID 指向面板 ID，即在异步回传期间自动展示里面的内容，算是最省事的无代码方案。

4. 分页与排序的 AJAX 化：让翻页不再翻车

4.1 AllowPaging 与自定义分页：数据量小的直接用，大的必须换

GridView 内置的 AllowPaging="true" 加上 PageSize 设置，就和自带的分页按钮一起工作了。默认情况下它做的是“假分页”：数据库查出来的是全表数据，GridView 在内存里只切出当前页显示。对行数少、数据量稳定的表完全可以这么做，因为简单可靠；但对一个几万行的表，每次翻页都全查一次再丢弃，就是纯浪费。

假分页的另一大问题是 ViewState 膨胀。数据源绑定的数据会被存进 ViewState，分页状态也存，导致隐藏字段越来越大。我之前调一个 50 行每页的表格，ViewState 干到 300 KB 后，页面加载都变慢。解决办法是关闭 ViewState，gvMain.EnableViewState="false"，然后把数据绑定放到 Page_Load 里每次都执行、同时按当前页码只取当前页数据，这就是真分页。

真分页和假分页的核心差异用一张表说清楚。

4.2 PageIndexChanging 事件里的取消默认行为

即便用真分页，GridView 的分页按钮和事件模型仍然可以直接复用。关键在一点：在 PageIndexChanging 事件里设置 e.NewPageIndex，然后重新绑定数据源。而如果你没有在事件里手动禁止默认行为，它会按照假分页的逻辑去取全表数据产生一条数据然后再用内存里切页。下面的写法是常规正确处理：

protected void gvMain_PageIndexChanging(object sender, GridViewPageEventArgs e) { gvMain.PageIndex = e.NewPageIndex; BindData(); }

BindData 里查询逻辑改成按页码跳过 offset。比如用 SQL Server 时，常见做法是：

-- 用 ROW_NUMBER 做分页查询，@PageSize 和 @PageIndex 由后端参数传入 SELECT * FROM ( SELECT ROW_NUMBER() OVER (ORDER BY Id DESC) AS RowNum, Id, Name, CreateTime FROM MyTable WITH (NOLOCK) ) AS T WHERE RowNum BETWEEN (@PageIndex - 1) * @PageSize + 1 AND @PageIndex * @PageSize

这个做法简单直接，但要小心排序字段重复的问题。ROW_NUMBER 的 ORDER BY 如果不唯一，翻页时可能出现同一条记录在不同页码出现或漏掉。稳妥做法是在 ORDER BY 后面补主键作为最终排序条件，保证顺序稳定。而对于 ORM 的情况，更推荐直接用 Skip 和 Take，例如 EF 的写法就是.OrderBy(x => x.Id).Skip((pageIndex - 1) * pageSize).Take(pageSize).ToList()，底层生成的 SQL 同样是 ROW_NUMBER 方案，逻辑一致。

4.3 排序事件与排序表达式白名单：性能和安全都要管

GridView 的排序默认会重新排序整个数据源再重新绑定。如果不做任何处理，它会触发表头的 LinkButton，带着 SortExpression 回传。我们一般希望把排序放到数据库层去执行，也就是把 SortExpression 直接拼接进 ORDER BY。但这正是 SQL 注入的经典入口，字段名来源是前端传值，绝不能直接拼。我的习惯是定义一个白名单字典，所有允许排序的字段和数据库真实列名对应，前端传过来的值只允许在字典键里找：

private static readonly Dictionary<string, string> SortWhitelist = new Dictionary<string, string>(StringComparer.OrdinalIgnoreCase) { { "id", "Id" }, { "name", "Name" }, { "createtime", "CreateTime" } }; protected void gvMain_Sorting(object sender, GridViewSortEventArgs e) { string columnName; if (!SortWhitelist.TryGetValue(e.SortExpression, out columnName)) { e.Cancel = true; return; } string sortDir = ViewState["SortDir"] == null ? "ASC" : ViewState["SortDir"].ToString(); if (ViewState["SortExpr"] != null && ViewState["SortExpr"].ToString() == columnName) { sortDir = sortDir == "ASC" ? "DESC" : "ASC"; } ViewState["SortDir"] = sortDir; ViewState["SortExpr"] = columnName; BindData(columnName, sortDir); }

这段代码处理了两件事。一是防注入，未知排序字段直接取消排序；另一个是排序方向切换，同一列第二次点击时自动反过来。还有一个小坑：GridView 的 AllowSorting 设为 true 后，默认会对所有绑定列的可排序列都生成排序链接，如果你有某列不想让用户排序，需要在 BoundField 上设置 SortExpression="" 来去掉。不看这一项的话，页面上会出现一个点击没反应的链接，用户会认为是 Bug。

4.4 一张表理清分页排序常见的参数配置项

下面这张表把常见的 GridView 分页排序相关参数汇总起来，方便做配置前对照检查。

5. GridView + AJAX 的四个大坑：现象、原因、解决一条龙

5.1 坑一：UpdatePanel 内点击后整页回传，异步不生效

现象：GridView 包在 UpdatePanel 里了，ScriptManager 也加了，但点击分页按钮页面还是整个刷新，F12 看到请求类型是 document 而不是异步回传的 post。

原因：最常见的有三种。一种是 ScriptManager 的 EnablePartialRendering 被设置成了 false；另一种是页面存在多个 ScriptManager，比如母版页和内容页各有一个；还有一种更隐蔽——GridView 放在 UpdatePanel 里，但分页按钮是通过代码动态生成的，或者在 RowCreated 里改了按钮类型，导致事件目标不在 UpdatePanel 的异步触发范围内。

解决：先检查页面上是否有重复的 ScriptManager，ASP.NET 会直接报错。再检查按钮是否满足异步触发条件（在面板内或显式配置了 AsyncPostBackTrigger）。动态生成的按钮建议改用工具类统一注册到触发列表。还有一个判断方式：在浏览器端用 Sys.WebForms.PageRequestManager.getInstance().get_isInAsyncPostBack() 在按钮点击后查一下，返回 false 说明压根没进入异步框架。

5.2 坑二：异步回传期间弹出“Sys.WebForms.PageRequestManagerParserErrorException”

现象：点击某个按钮后，页面弹出 JavaScript 错误，提示“传递给服务器的消息无法分析，通常是因为服务器响应中修改了页面的 Response.Write 调用”，其实质是服务器返回的不是可解析的 HTML 片段而是一段普通文本。

原因：UpdatePanel 异步回传时，服务器响应必须是特定格式的分块数据；如果你的页面生命周期中有任何代码直接使用了 Response.Write、Response.Redirect、Response.End，这些都会破坏响应格式。常见的是在分页事件或点击事件里 Response.Redirect("其他页面")，异步回传时这个跳转不会正常执行，反而直接报错。

解决：需要跳转页面就不要在事件里直接 Redirect，改为注册客户端脚本，在回传完成后再执行：

// 异步回传环境中重定向必须延迟到客户端执行 string redirectScript = "window.location.href='DetailPage.aspx?id=" + id + "';"; ScriptManager.RegisterStartupScript(this, this.GetType(), "redirect", redirectScript, true);

RegisterStartupScript 的第五个参数 true 表示自动包裹 script 标签并执行，这是 UpdatePanel 场景下最标准的跳转写法。还有 Response.Write 这类输出，一律改成页面上的 Label 控件显示，不要直接流式输出。

5.3 坑三：翻页后自定义事件失效，行按钮点击没反应

现象：第一次加载页面时，GridView 的行内按钮能正常触发事件，点击翻页后再点击行内按钮，事件不触发，或者找不到数据行。

原因：GridView 在每一次回传时都会执行 RowCreated 和 RowDataBound，如果你在这两个事件里给行内的按钮挂了事件委托，或者设置了 CommandName，翻页后异步回传会重新渲染整个表格，而 ViewState 中保存的状态可能已经和重新创建的行控件对不上。另一个常见场景是：按钮是模板列里的，事件绑定写的 Button.Click += 一行代码，但没判断是否重复绑定，导致翻页后绑多次。

解决：凡是依赖行内控件的逻辑，都放到 RowCommand 或 RowDataBound 里统一处理，不要在代码里对按钮单独 Attachment 事件。行按钮建议直接用 CommandName，配合 CommandArgument 传行索引或主键值，在 RowCommand 里统一处理：

protected void gvMain_RowCommand(object sender, GridViewCommandEventArgs e) { if (e.CommandName == "EditRow") { int id = Convert.ToInt32(e.CommandArgument); // 根据 id 加载数据、切换到编辑状态 } }

同时确认模板列按钮的 CausesValidation="false"，部分按钮默认会触发校验，校验不通过时回传事件会被取消，导致看起来像点击无反应。

5.4 坑四：异步刷新后页面 JavaScript 失效，已经绑定的插件全部失效

现象：用 UpdatePanel 刷新后，表格外层的 JS 插件，比如日期选择器、下拉筛选、固定表头，全部失灵。有时候表格重新渲染后里面的 input 点一下没反应。

原因：页面首次加载时你手动初始化的 JS 插件，针对的是当时页面上的 DOM 元素。UpdatePanel 异步更新后，旧的 DOM 节点被替换成全新的节点，之前绑在旧节点上的事件和插件实例也随之销毁。新节点没有重新初始化，自然没有效果。很多人以为这是 UpdatePanel 的 Bug，其实是前端生命周期管理问题。

解决：把初始化代码放到 PageRequestManager 的 endRequest 事件里重新执行，或者，如果你的插件是用 jQuery 写的，用事件委托的方式绑定，让事件挂到容器层而不是具体元素上。endRequest 版写法如下：

Sys.WebForms.PageRequestManager.getInstance().add_endRequest(function (sender, args) { // GridView 更新后重新初始化表格内的日期控件 $("#gvMain .date-input").datepicker({ dateFormat: "yy-mm-dd" }); });

值得提醒的是，这段代码要放在页面加载之后执行，并且保证只初始化当前存在的元素，重复执行时先销毁再初始化，避免同一控件被初始化两次导致样式错乱。

6. 更进一步：抛弃 UpdatePanel，用 WebMethod 把 GridView 变成真 AJAX

6.1 WebMethod 返回 JSON：数据接口的搭建思路

如果你的场景对响应速度要求更高，最好用的轻量改造是把 GridView 的数据查询抽成 WebMethod，前端自己发起异步请求，拿 JSON 后拼接表格行。这个方案的优点很直接：后端不用再走完整页面生命周期，不加载 ViewState，不重新渲染整个页面，也不触发任何无关事件。缺点是需要自己处理和 GridView 相关的交互逻辑，比如编辑、删除、分页状态保持。

先搭服务器端接口。在 aspx 页面或者独立的 aspx.cs 文件里创建一个方法，用 [WebMethod] 特性标注，通过 PageMethods 调用。下面是一个最小示例：

[System.Web.Services.WebMethod] public static object GetPageData(int pageIndex, int pageSize, string sortExpr, string sortDir) { // 参数校验不能省 pageIndex = pageIndex < 1 ? 1 : pageIndex; pageSize = pageSize > 100 ? 100 : pageSize; using (var db = new MyDbContext()) { var query = db.Products.AsNoTracking(); // 排序白名单在服务端再校验一次 query = ApplySort(query, sortExpr, sortDir); var items = query .Skip((pageIndex - 1) * pageSize) .Take(pageSize) .Select(p => new { p.Id, p.Name, p.Price, p.CreateTime }) .ToList(); int total = query.Count(); return new { rows = items, total = total }; } }

6.2 前端用 fetch 替换 UpdatePanel，渲染表格行和分页条

前端拿到 JSON 后，禁用 GridView 原有的分页按钮，改用自己生成的分页链接。也可以直接隐藏 GridView，用纯 HTML table 替换掉它，行内按钮直接绑定 onclick 调用 WebMethod。这里给出最核心的一段 JS：

function loadPage(pageIndex) { fetch("MainPage.aspx/GetPageData", { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ pageIndex: pageIndex, pageSize: 20, sortExpr: currentSort, sortDir: currentDir }) }) .then(function (r) { return r.json(); }) .then(function (data) { if (data.d && data.d.rows) { renderTable(data.d.rows); renderPager(pageIndex, data.d.total); } }); }

注意 WebMethod 返回的对象会包一层 .d，这是 ASP.NET 对 JSON 调用的一层封装，很多第一次写的人会在这里拿到 undefined。另外，fetch 的 URL 格式是页面文件名.aspx/方法名，不要写错或带上虚拟路径。renderTable 函数里直接用 innerHTML 拼接 tr 和 td，数据量大时建议用 DocumentFragment 或 createElement 组装，避免多次操作 DOM 导致页面卡顿。

6.3 编辑与删除事件的 AJAX 化改造经验

行内编辑和删除在 WebMethod 模式下，每个操作单独建一个接口，比如 DeleteItem(int id)、UpdateItem(int id, string field, string value)。按钮直接调用对应接口，操作成功后刷新当前页数据。有一个细节值得提一下：操作失败时要返回可读的错误信息，不要把 C# 异常直接抛给前端。在 WebMethod 里捕获异常返回标准格式：

try { // 执行删除逻辑 return new { success = true }; } catch (Exception ex) { return new { success = false, message = ex.Message }; }

前端判断 success 为 false 时提示 message。这样操作出错时用户看得到原因，而不是页面毫无反应。我给自己定过一个要求：所有异步操作，必须考虑“失败时怎么提示”，否则就不要上线。这会显著减少“点了没反应”类的工单。

6.4 什么时候建议走这条路线，什么时候千万别走

如果你维护的项目是纯 WebForms 的老系统，而且业务报表多、查询条件杂，WebMethod 方案反而会增加开发量，因为你把原先 GridView 自带的分页排序都拆成了自己写。我建议只有满足以下条件时才用：数据量大到 UpdatePanel 明显卡顿，或者产品上需要做复杂交互（列拖拽、固定表头、批量选择）而 GridView 已无法满足。否则，在最省力的前提下，UpdatePanel 依然是老项目体验升级的首选。

个人习惯是把这两条路线当成一个整体来考虑：前期表格结构稳定了，先用 UpdatePanel 快速交付；等用户反馈速度不满意、数据规模确实上来了，再把最热的那几个页面逐个转换为 WebMethod 模式。这样做的好处是，每一阶段都有明确收益，不需要在项目初期做一次大重构。经验里还有一条铁律：任何改造前先打开 F12。不管新代码还是维护代码，我都会先手动触发一次 GridView 翻页，看一眼 Network 面板里请求大小和类型。如果请求只有几 KB，说明局部刷新在正常干活；如果还是 MB 级的整页文档，那再好的优化硬件也救不回来。希望这篇笔记能让你少走点弯路，翻页不白屏，用户不抱怨，才是表格开发里最朴素的成就感。

本文还有配套的精品资源，点击获取