简介面向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 效果之间还隔着一层没做好的封装。这个标题里的“gridviewasp.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 再省事也不值得迁就。这里给一张简单的方案选型表取舍逻辑写清楚。改造路线改动量服务器负载适合场景需注意的问题UpdatePanel 包裹 GridView最小纯页面改动服务器仍全跑生命周期数据库查询不省老系统快速改善体验ViewState 过大、页面内容过重时不明显前端 AJAX WebMethod 返回 HTML中等需拆接口生命周期不再走只执行方法大数据量、频繁分页排序需自行处理行事件、数据状态全套前后端分离大需重写最优新项目或长线维护方案本身和 GridView 没有关系了2.3 三种 AJAX 改造路线的对比与选型判断之前给某公司维护过一个十年的老系统表格全部是 GridView每页 100 行、2000 行数据。分页一次F12 看请求体积在 1.6 MB 左右点一下要等 2 到 3 秒。第一轮改造我选择的是给所有 GridView 套 UpdatePanel效果立竿见影不再白屏滚动条保住带宽占用降了大半。但点分页那一瞬间还是会有半秒的顿挫原因是服务器端依然全量绑定数据。第二轮改造我把其中一张数据量最大的表拆成 WebMethod 接口前端用原生 JavaScript 发请求返回的是拼好的 HTML 行。这下速度才真正起来了。结论其实很朴实UpdatePanel 解决的是“刷新感”接口方案解决的是“计算量”。表格数据量在千行以内、交互不频繁UpdatePanel 足够数据大、操作频繁就必须把数据绑定和数据渲染压到最轻。本文后面的章节会分别给出这两条路线的落地方案。3. 最小改造方案十分钟给 GridView 套上 UpdatePanel3.1 页面结构改造ScriptManager 与 UpdatePanel 的正确位置WebForms 项目里要启用 UpdatePanel第一个前提是页面上必须有且只有一个 ScriptManager。ScriptManager 可以放在任意位置但习惯上是放在 form 标签内最顶部。UpdatePanel 放在页面下方把 GridView 整体包进去。下面这段代码结构是最小可用方案直接复制调整即可。asp:ScriptManager IDScriptManager1 runatserver EnablePartialRenderingtrue / asp:UpdatePanel IDupGrid runatserver UpdateModeAlways ContentTemplate asp:GridView IDgvMain runatserver AutoGenerateColumnsFalse DataKeyNamesId OnPageIndexChanginggvMain_PageIndexChanging Columns asp:BoundField DataFieldId HeaderText编号 / asp:BoundField DataFieldName HeaderText名称 / asp:BoundField DataFieldCreateTime 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 IDupList runatserver UpdateModeConditional ContentTemplate asp:GridView IDgvList runatserver ... / /ContentTemplate Triggers asp:AsyncPostBackTrigger ControlIDbtnSearch EventNameClick / /Triggers /asp:UpdatePanel asp:UpdatePanel IDupStat runatserver UpdateModeConditional ContentTemplate asp:Label IDlblTotal runatserver / /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前端放一个 UpdateProgressAssociatedUpdatePanelID 指向面板 ID即在异步回传期间自动展示里面的内容算是最省事的无代码方案。4. 分页与排序的 AJAX 化让翻页不再翻车4.1 AllowPaging 与自定义分页数据量小的直接用大的必须换GridView 内置的 AllowPagingtrue 加上 PageSize 设置就和自带的分页按钮一起工作了。默认情况下它做的是“假分页”数据库查出来的是全表数据GridView 在内存里只切出当前页显示。对行数少、数据量稳定的表完全可以这么做因为简单可靠但对一个几万行的表每次翻页都全查一次再丢弃就是纯浪费。假分页的另一大问题是 ViewState 膨胀。数据源绑定的数据会被存进 ViewState分页状态也存导致隐藏字段越来越大。我之前调一个 50 行每页的表格ViewState 干到 300 KB 后页面加载都变慢。解决办法是关闭 ViewStategvMain.EnableViewStatefalse然后把数据绑定放到 Page_Load 里每次都执行、同时按当前页码只取当前页数据这就是真分页。真分页和假分页的核心差异用一张表说清楚。分页方式数据库访问内存占用ViewState 大小适用数据量实现难度自带假分页每次查全表高大千行以内零真分页 SQL ROW_NUMBER每次只查一页低小万级以上中真分页 存储过程每次只查一页低小万级以上中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 Dictionarystring, string SortWhitelist new Dictionarystring, 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 分页排序相关参数汇总起来方便做配置前对照检查。配置项属性或事件建议值说明每页行数PageSize10、20 或 50超过 100 行建议考虑分批加载或虚拟滚动总行数展示自行查询COUNT(*)配合 PagerTemplate 显示第 x / y 页排序状态AllowSortingtrue需要配合 Sorting 事件做白名单处理排序字段持SortExpression设为空字符串可禁用单列排序对应 BoundField 直接设置分页行为PageIndexChanging必须写事件并重新绑定不写就用内存假分页ViewStateEnableViewState假分页开真分页关真分页关了可大幅瘦身数据绑定时机Page_Load只在 !IsPostBack 时绑定初始数据翻页、排序事件里单独绑定5. GridView AJAX 的四个大坑现象、原因、解决一条龙5.1 坑一UpdatePanel 内点击后整页回传异步不生效现象GridView 包在 UpdatePanel 里了ScriptManager 也加了但点击分页按钮页面还是整个刷新F12 看到请求类型是 document 而不是异步回传的 post。原因最常见的有三种。一种是 ScriptManager 的 EnablePartialRendering 被设置成了 false另一种是页面存在多个 ScriptManager比如母版页和内容页各有一个还有一种更隐蔽——GridView 放在 UpdatePanel 里但分页按钮是通过代码动态生成的或者在 RowCreated 里改了按钮类型导致事件目标不在 UpdatePanel 的异步触发范围内。解决先检查页面上是否有重复的 ScriptManagerASP.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.hrefDetailPage.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 加载数据、切换到编辑状态 } }同时确认模板列按钮的 CausesValidationfalse部分按钮默认会触发校验校验不通过时回传事件会被取消导致看起来像点击无反应。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 变成真 AJAX6.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。这里给出最核心的一段 JSfunction 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 级的整页文档那再好的优化硬件也救不回来。希望这篇笔记能让你少走点弯路翻页不白屏用户不抱怨才是表格开发里最朴素的成就感。本文还有配套的精品资源点击获取