返回上一页怎么做才好？优化用户体验这样做！

要说这个“返回上一页”，看着简单，但真要做那学问可大了去了。我以前也觉得，不就是个浏览器自带的功能嘛或者代码里写个，多简单的事儿。结果，吃了不少苦头，才明白这里面的道道。

为啥我非要折腾这个？说起来也是一肚子苦水。那会儿我刚接了个私活，帮我一个哥们儿弄个小电商网站，卖点他们本地的土特产。网站后端我学着用了点新东西，前端就图个快，想着能用就行。结果刚上线没多久，我哥们儿就给我打电话，语气那叫一个急！

他跟我说，有个顾客下单买了好几样东西，填了一大堆收货地址、联系方式，眼看都要付款了，结果不小心点了个什么地方，一下就回到商品详情页了。再想回购物车，点返回，直接给他回到首页了！气的顾客直接不买了，说他们网站用着太麻烦了。

我当时就懵了，不可能，我用的都是标准组件，按理说浏览器自带的“返回”功能没问题。后来我亲自上手试了试，果不其然。从购物车页面点进商品详情，再点返回，有时候真就回不到购物车，而是跳到更早的页面，或者直接卡在那儿，数据全没了。最恼火的是，有些表单页面，比如填写收货地址的，提交完了，显示成功，用户一看想再确认下，点个返回，结果又回到那个空白的收货地址表单了！辛辛苦苦填的，瞬间白费。

用户到底想返回哪儿？

我那会儿是真的郁闷，感觉这小项目把我整得焦头烂额。晚上躺在床上想了好久，才意识到一个问题：用户嘴里说的“返回上一页”，跟浏览器“历史记录里的上一页”，根本不是一回事！

用户想的“返回”，通常是回他来时的那个页面，或者他觉得“逻辑上”应该回去的那个页面。比如从列表页点进商品详情，他想回的是那个列表页；从购物车去结算页，他想回的是购物车；从某个编辑表单提交成功后，他想回的是那个编辑成功后的展示页，而不是空白表单。

这事儿逼得我下定决心，必须得把这个“返回”功能给优化

我动手是这么做的

我琢磨了好几天，决定不能再依赖浏览器自带的历史记录了，得自己给它“指路”。

• 第一步，明确用户意图。 我开始在每个可能会跳转的页面，比如商品详情、订单详情、文章详情等等，都加了一个小逻辑。当用户从列表页A跳转到详情页B的时候，我会在详情页B的URL里偷偷带上一个参数，比如?from=listA，或者存到session里。
• 第二步，定制返回按钮。 我把页面上那些原本只是简单用的“返回”按钮，都改成了我自己的逻辑。当用户点击“返回”的时候，我不再直接调用浏览器历史，而是先去看看当前页面URL里有没有from参数，或者session里有没有我之前存的跳转来源。
• 第三步，分情况处理。
  • 如果找到了来源信息，比如from=listA，那我就直接用代码跳转回那个listA页面。这样不管用户在详情页里又点了多少次链接，只要他点的是我这个定制的“返回”，他都能准确回到他一开始来的那个列表页。
  • 如果没找到来源信息，那就说明用户可能是直接输入URL进来的，或者从其他不记录来源的地方跳转过来的。这时候我也不慌，我会给他一个“保底”的方案。比如，如果当前是某个商品的详情页，保底就跳回商品列表页；如果是某个文章的详情页，就跳回文章列表页。确保他不会迷路，总有个地方可以去。
  • 特别是一些表单页面，比如地址填写、资料修改什么的。我特地加了一层处理。如果用户提交成功了，下次他点“返回”，我会直接让他跳转到对应的展示页面，而不是让他回到那个空的表单。这样他就能看到他刚刚更新的资料了。如果他没提交，只是在表单里修改了一些东西，不小心点了返回，我还会弹个提示，问他“你还没保存，确定要放弃吗？”这样避免他辛苦填的数据白费。

这一套下来，我哥们儿网站上的用户投诉瞬间就没了。他给我打电话，语气里都是轻松，说好多老顾客都留言说网站变好用了，操作起来顺手多了。我自己也去试了试，那种“指哪打哪”的感觉，确实舒服。再也没有那种“我点返回，它却把我带到莫名其妙的地方”的抓狂感了。

别小看一个“返回上一页”的小按钮，它背后藏着用户最真实的心理预期。把这个功能做好了，用户体验立马就能上一个大台阶。