async
问题引入
当前我的图片网站是使用http请求获取数据 每次下拉触底触发游标查询 响应结果自然是图片列表
但是观察bing的图片功能时 发现它使用的是下划加载时并没有显式触发http请求 仔细看图片是由
这样一个ansync请求得来的
这是什么 与我的http方式有何不同
传统的HTTP请求通常是每次滚动到底部时发送一个GET请求，获取新数据，然后更新页面。
而async请求可能涉及的是异步加载技术，比如使用AJAX或者Fetch API，但提到说没有触发HTTP请求，这不太对，因为任何数据加载都需要HTTP请求。可能观察到的是请求的URL参数不同，或者请求方式不同，比如用了GET但看起来不像传统的页面加载。
async请求可能指的是异步加载，但具体到Bing的案例，可能是在使用分页或无限滚动技术，但通过更优化的参数传递，比如first参数控制起始位置，count控制数量，这样每次加载更多的数据，而不需要传统的分页按钮。
误解了“没有触发HTTP请求”，实际上还是有请求的，只是可能用了异步的方式，没有页面刷新，所以用户感觉不到明显的请求。
另外，Bing的URL中有很多参数，比如first=70，count=35，这可能是在分页，每次加载下一页的数据。
而传统的HTTP请求可能每次都是新的请求，而async可能是在同一个页面中通过AJAX请求，动态加载更多数据，避免页面刷新，提升用户体验。
Bing是否使用了流式加载、长轮询，或者其他技术如WebSockets？
但根据提供的URL，看起来是普通的GET请求，参数控制分页。
因此，可能问题在于如何实现无刷新的无限滚动，而Bing的async请求可能只是异步的分页请求，通过参数调整来加载更多数据。
需要解释两种方式的不同：传统的HTTP请求可能每次都是完整的页面加载或者明显的AJAX请求，而Bing的async请求可能通过动态修改URL参数，并且使用前端框架（如React、Vue）来更新DOM，让用户感觉不到页面刷新，或者使用更高效的异步加载策略，比如预加载或更智能的分页逻辑。 另外，可能涉及到服务端的分页实现方式，比如游标分页（cursor-based pagination）与传统的分页参数（如page和pageSize）的区别。
Bing可能使用游标来跟踪当前的位置，而当前的系统可能使用简单的分页参数，每次请求下一页时增加页码。
async
Bing的async请求模式解析
技术原理 Bing的/images/async接口是典型的无限滚动（Infinite Scroll）实现，通过异步分页加载实现数据动态加载。
关键参数：
first=70：表示从第70条结果开始加载。
count=35：每次加载35条数据。
dgState等参数：用于记录滚动位置、分页状态等。
请求方式：通过GET请求发送，返回JSON或HTML片段，前端动态渲染。
实现特点
无页面刷新：通过AJAX/Fetch异步请求，避免页面跳转或刷新。
动态分页：通过参数控制加载位置和数量，实现“按需加载”。
SEO友好：直接访问URL参数可跳转到对应分页位置。
与传统HTTP请求方式的对比
Bing模式的优势
性能优化
减少传输量：仅返回增量数据（如35条图片信息），而非完整页面
并行加载：可预加载下一页数据，提升响应速度。
用户体验提升
无缝滚动：用户无需等待页面刷新，降低操作中断感。
灵活分页：支持动态调整分页大小（如count参数）。
技术兼容性
后端友好：可通过参数直接控制分页逻辑，无需复杂状态维护。
前端实现简单：基于标准AJAX/Fetch API即可实现。
如何改进当前系统？
实现无限滚动
前端：监听滚动事件，触发/api/pictures?offset=70&limit=35等异步请求。
后端：根据offset和limit参数分页查询数据库，返回JSON数据。
优化分页参数
使用offset和limit替代传统page参数，支持更灵活的分页逻辑。
可引入游标分页（如before/after时间戳），避免因数据变化导致的分页错乱。
减少传输数据量
仅返回必要的字段（如图片URL、宽度、高度等），避免冗余数据。
预加载优化
在用户滚动到接近底部前，提前发起下一组数据的请求，提升响应速度。
项目分区导航：⬅️ 08-自适应瀑布流下拉加载游标查询 | 09-async | ➡️ 10-SSE流程
💬 评论