这个问题自己之前关注过。其实这涉及到一个用户体验的问题(尽管我也不大明白神马叫用户体验)。现在一般提供的分页有以下前两种方式。
1、第一种像你所说的，告诉总的页数，以及每页固定的记录数。这种方式下有一个问题：有时候用户其实根本不关心你总共有多少条记录，她只是想随便看看，而且一般只浏览个前几十条就差不多了。但是这种方式也有一个优点：对于一些目标指向性明确的用户，例如他就直接只关注第XX页的记录，这个时候就可以通过分页条基本上一步就过去了。技术上的实现，我更多的是倾向于你所列的第二种方法。对于有分页需求，这种方法其实算不上耦合很紧，因为总页数和当前页的数据记录都是用户所需要的信息。而且一次交互就能实现，简单直接。再说在china，网络速度你知道滴，交互能少些还是少点好。
2、第二种，有点类似你所说的第一种方法，只提供当前页的记录信息，但只保留一次交互，不提供总的页数信息。当用户浏览到最后一条记录时，再滚动条下滑时会继续加载下一页的信息，也就是前端所说的瀑布流。这种方式与第一种方式相反，符合那种只关心前XX条信息的用户需求，但对于目标指向性明确的用户就悲剧了，用户得不同的下滑滚动条加载下一页，而且还不知道什么时候该结束。这种方法的技术上实现就简单了，一次服务调用提供当前页的记录信息即可。
3、第三种，综合第一种和第二种方式。先提供瀑布流的方式的方式，满足那种只是随便浏览，只关注前XX记录信息的用户。当加载到一定条数的时候，就不再采用瀑布流了，而是转为分页，满足目标指向性明确的需求，跳到自己关心的那一页。新浪微博Web版就是采取这种方式实现的，第一次只加载20条记录，当浏览到最后一条再下滑滚动条时，继续加载20页，两次加载完毕后，如果用户还想记录关注，那提供一个分页条，其中每页包含40条记录，当前已加载的40条记录就默认为第1页(凭印象写的，可能和新浪微博的实际采用方式有出入，如有出入请忽略之，另自行查证)。技术上这种实现相比第一种和第二种相对复杂一点，但用户体验好很多。只是在默认第一页的时候把一次交互拆分为两次，后续的就是你所描述的第二种分页方式。
一切的一切，都是基于你的需求所做取舍，自己权衡利弊吧，技术上实现不应该成为瓶颈，只是为满足需求。
