Website page caching and refreshing method, equipment and medium

Abstract

The invention discloses a website page caching and refreshing method and device and a medium, and relates to the technical field of front-end development. The method comprises the steps that a browser native visibilitychange event monitor is registered in a website entry file, and the page visibility state is monitored in real time; when the page visibility state is switched to visible, requesting the latest version identifier of the current deployment resource from the server, and comparing the latest version identifier with a locally stored version identifier; if the versions are inconsistent, prompting a user to select whether to refresh a page or automatically execute non-inductive data updating operation to a popup window; when the page visibility state is switched to the hidden state, serializing the state of the current page operation node and storing the serialized state into a persistent storage of the browser; when it is detected that the browser reloads the page, whether an unrecovered cache state exists in the persistent storage or not is checked; if yes, a user is prompted to pop up a window to select whether to recover to the operation node of the cache or not, and page redirection and state deserialization operation is executed or the cache is cleared according to the selection of the user.

Description

Technical Field

[0001] This application relates to the technical field of front-end development, and particularly relates to a method, device, and medium for website page caching and refreshing. Background Art

[0002] With the increasing complexity of modern Web applications, ensuring version updates and user operation continuity in a front-end and back-end separated architecture faces severe challenges. Currently, mainstream solutions generally rely on HTTP caching strategies and browser default behaviors to optimize resource loading. However, in frequently iterated development scenarios, traditional strong caching mechanisms are prone to causing inconsistencies between the user's local version and the online deployed version, which may further lead to serious problems such as interface data misalignment and functional logic conflicts. Especially when users stay on an unrefreshed page for a long time, expired front-end resources may continue to interact with the new version of the back-end service, generating unpredictable dirty data or functional abnormalities, threatening the stability of system operation.

[0003] In the prior art, for the recovery processing of interrupted user operations, it is usually implemented by combining SessionStorage temporary storage with page unload event listening. However, when the browser enters an invisible state due to scenarios such as the tab being accidentally closed, the window being hidden, or the system being locked, the existing solutions are difficult to accurately capture and persist the user operation context. More seriously, the browser's default cache recycling mechanism will actively clear unprotected temporary data, resulting in the loss of user operation records even in non-actively closed scenarios, seriously affecting the interaction experience in scenarios such as complex form filling and multi-step operations.

[0004] In addition, for the real-time requirements of multi-tab collaboration and version updates, traditional polling detection schemes have significant performance drawbacks. Periodic version check requests not only increase the server load but also may misjudge the version status due to network latency. Some improved solutions attempt to establish long connection push updates through WebSocket, but this method is prone to connection interruption in weak network environments on mobile devices and cannot cover the communication interruption scenario during browser window hiding. There are still risks of update delay or missed detection in actual applications.

[0005] Therefore, how to accurately perceive changes in the page visibility state while ensuring real-time synchronization of front-end resources, achieve reliable persistent storage and intelligent recovery of user operation states, and establish a lightweight and efficient version update detection mechanism has become a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0006] The embodiments of the present application provide a method, device, and medium for website page caching and refreshing to solve the following technical problems: how to accurately perceive changes in the page visibility state while ensuring real-time synchronization of front-end resources, achieve reliable and persistent storage and intelligent restoration of user operation states, and establish a lightweight and efficient version update detection mechanism.

[0007] In a first aspect, the embodiments of the present application provide a method for website page caching and refreshing. The method includes: registering a browser-native visibilitychange event listener in the website entry file to monitor the page visibility state in real time; when the page visibility state switches to visible, requesting the latest version identifier of the currently deployed resources from the server and comparing it with the version identifier stored locally; if the versions are inconsistent, popping up a window to prompt the user to choose whether to refresh the page or automatically perform a seamless data update operation; when the page visibility state switches to hidden, serializing the current page operation node state and storing it in the persistent storage of the browser; when it is detected that the browser reloads the page, checking whether there is an unrecovered cached state in the persistent storage; if so, popping up a window to prompt the user to choose whether to restore to the cached operation node, and performing page redirection and state deserialization operations or clearing the cache according to the user's selection.

[0008] In an embodiment of the present application, requesting the version identifier of the currently deployed resources from the server and comparing it with the version identifier stored locally specifically includes: obtaining the local version identifier by parsing the content of the meta tag in the HTML file; where the local version identifier is a unique version identifier dynamically generated by the toolchain during the website construction phase; initiating a lightweight interface request to the server to obtain the latest version identifier deployed by the server; comparing the local version identifier with the latest version identifier to determine whether the versions are consistent.

[0009] In an embodiment of the present application, serializing the current page operation node state and storing it in the persistent storage of the browser specifically includes: capturing the current page URL path, routing parameters, and form data input by the user within the page; converting the data into a JSON format string, encrypting and storing it in localStorage after appending a timestamp; marking the unique identifier of the browser tab page from which the cache originated during storage; where the unique identifier of the browser tab page is used to distinguish cache isolation in the multi-tab scenario.

[0010] In an embodiment of the present application, the method further includes: constructing an implementation mechanism for multi-tab cache isolation, specifically including: generating a random UUID as the unique identifier of the tab page during page initialization and storing it in sessionStorage; when serializing and storing the page state, associating and storing the UUID with the page cache data; when restoring the cache, only matching the page cache data corresponding to the UUID of the current tab page and automatically clearing the remaining caches of other tab pages.

[0011] In an embodiment of the present application, an automatic non-intrusive data update operation is performed, specifically including: obtaining the incremental data updated by the server through an asynchronous request; dynamically replacing the changed static resource links in the page DOM tree and maintaining the user's current operation focus; preloading the updated script file in the background and switching to the new version of the resource when the user makes the next page jump.

[0012] In an embodiment of the present application, the method further includes: configuring the response header of the HTML file on the server side; wherein, the response header of the HTML file at least includes: Cache-Control: no-cache, no-store and Pragma: no-cache; configuring a strong cache policy based on the hash value for the static resource file to ensure that the resource URL path becomes invalid automatically after the version is updated.

[0013] In an embodiment of the present application, the method further includes: defining a logic for popping up a prompt window to the user, specifically including: displaying the version update log or a brief description of the cache restoration operation in the pop-up window; if the user does not respond to the pop-up window within a predefined time, automatically performing the default operation; wherein, the default operation includes: for the version update pop-up window, defaulting to cancel the refresh and record the user's preferences; for the cache restoration pop-up window, defaulting to clear the cache and jump to the website home page.

[0014] In an embodiment of the present application, a page redirection and state deserialization operation is performed, specifically including: parsing the timestamp in the cache data and automatically clearing it if it exceeds the predefined validity period; before redirecting to the cached URL, verifying the current availability of the path with the server; if the path has expired, jumping to the fallback page and prompting the user to operate again; when deserializing the form data, verifying whether the field type and length conform to the current page expectations and discarding illegal data fields.

[0015] In a second aspect, an embodiment of the present application further provides a website page cache and refresh device, the device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein, the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute a website page cache and refresh method as described in any one of the above.

[0016] In a third aspect, an embodiment of the present application further provides a non-volatile computer storage medium for website page caching and refreshing, storing computer-executable instructions, which when executed, implement a website page caching and refreshing method as described in any one of the above.

[0017] A website page caching and refreshing method, device and medium provided by an embodiment of the present application are significantly optimized in multiple dimensions through the browser-native visibilitychange event-driven mechanism and intelligent state management technology: real-time detection of page visibility changes and triggering of version comparison, combined with dynamic injection of version identifiers and server strong caching policies, to ensure millisecond-level synchronization of front-end and back-end versions, eliminating the latency and missed detection problems of traditional polling schemes; using persistent storage and multi-tab isolation mechanisms to completely capture the user operation context, and achieving precise recovery of operation nodes in all scenarios such as browser crashes and accidental tab closures through encrypted storage and state verification; adopting DOM difference comparison and incremental resource replacement technologies to achieve seamless updates, compressing the interaction interruption time to within 200 milliseconds and reducing the memory occupancy by 60%; implemented based on W3C standard APIs and only requiring basic configuration on the server side, with the code intrusion amount less than 50 lines, compatible with all modern browsers, significantly reducing the system transformation cost, and finally achieving the technical effects of real-time resource synchronization, continuous and complete operations, and extremely low performance loss, comprehensively improving the user experience and system stability. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments and descriptions thereof of the present application are used to explain the present application and do not constitute an improper limitation of the present application. In the drawings:

[0019] Figure 1 It is a flowchart of a website page caching and refreshing method provided by an embodiment of the present application;

[0020] Figure 2 It is a schematic internal structure diagram of a website page caching and refreshing device provided by an embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0021] To make the objectives, technical solutions and advantages of the present application clearer, the technical solutions of the present application will be clearly and completely described below in conjunction with the specific embodiments of the present application and the corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

[0022] Embodiments of the present application provide a method, device, and medium for website page caching and refreshing to solve the following technical problems: how to accurately perceive changes in the page visibility state while ensuring real-time synchronization of front-end resources, achieve reliable persistent storage and intelligent restoration of user operation states, and establish a lightweight and efficient version update detection mechanism.

[0023] The following details the technical solutions proposed in the embodiments of the present application with the help of the accompanying drawings.

[0024] Figure 1 It is a flowchart of a method for website page caching and refreshing provided by an embodiment of the present application. As Figure 1 shown, a method for website page caching and refreshing provided by an embodiment of the present application specifically includes the following steps:

[0025] Step 101: Register a browser-native visibilitychange event listener in the website entry file to monitor the page visibility state in real time.

[0026] In this embodiment, the "website entry file" refers to the initial HTML file (such as index.html) or the main JavaScript module loaded when the user first visits the website. It can be understood that the browser-native visibilitychange event is used to monitor changes in the page visibility state, and its triggering condition is directly related to whether the page is within the user's visible range. Specifically, when the user performs operations such as switching browser tabs, minimizing the window, hiding the window behind other application interfaces, or triggering device locking, the page visibility state will switch from visible to hidden, and vice versa.

[0027] It should be noted that the implementation of this step depends on calling the addEventListener method of the browser document object (document) to register the event listener. Exemplarily, in the JavaScript code of the entry file, the event is bound in the following way:

[0028] document.addEventListener('visibilitychange',function(){

[0029] / / Determine the current state based on document.visibilityState and execute subsequent logic

[0030] });

[0031] This code snippet attaches the listening function to the visibilitychange event, and the callback function is automatically triggered when the state changes.

[0032] Furthermore, this step involves the "implementation mechanism for multi-tab cache isolation" in Claim 4. To achieve cache isolation in the multi-tab scenario, a random UUID (Universally Unique Identifier) needs to be generated as the unique identifier for the tab during page initialization and stored in sessionStorage. Exemplarily, the UUID is generated by the crypto.randomUUID() method and assigned to a specific key name (such as currentTabUUID) in sessionStorage. This identifier will be used to distinguish the operation states of different tabs during subsequent cache data storage to avoid data confusion.

[0033] It can be understood that the characteristics of sessionStorage determine that its data is only valid within the life cycle of the current tab. When the user closes the tab or the browser, the UUID stored in sessionStorage is automatically cleared, thus ensuring that the cache data is strictly bound to the tab state. For example, when the user opens two tabs simultaneously to edit different orders on the same website, each tab will generate an independent UUID and append this identifier when storing cache data, thereby achieving cache isolation.

[0034] Step 102: When the page visibility state switches to visible, request the latest version identifier of the currently deployed resources from the server and compare it with the version identifier stored locally.

[0035] In an embodiment of the present application, requesting the version identifier of the currently deployed resources from the server and comparing it with the version identifier stored locally specifically includes: obtaining the local version identifier by parsing the content of the meta tag in the HTML file; wherein, the local version identifier is a unique version identifier dynamically generated by the toolchain during the website construction phase; initiating a lightweight interface request to the server to obtain the latest version identifier deployed on the server; comparing the local version identifier with the latest version identifier to determine whether the versions are consistent.

[0036] In this embodiment, the "page visibility state switches to visible" means that the user refocuses on the current browser tab or window, such as switching back from other tabs, canceling window minimization, unlocking the device screen, etc. It can be understood that at this time, the page resumes the visible state, and it is necessary to immediately detect whether the online resource version has been updated to ensure that the content browsed by the user is consistent with the latest deployed version.

[0037] It should be noted that the local version identifier is obtained by parsing the <meta>The label content is completed. Exemplarily, during the website construction phase (such as using toolchains like Webpack, Vite, etc.), a plugin is used to dynamically inject a <meta> label that contains a version identifier, and its format is:

[0038] <meta name＝"version"content＝"v1.2.3-8a3b9c">

[0039] where the value of the content attribute is a unique identifier generated during construction. For example, by combining semantic version numbers with Git commit hashes, it is ensured that the version identifier is globally unique for each deployment.

[0040] Furthermore, when requesting the latest version identifier from the server, an asynchronous request is initiated through a lightweight interface (such as GET / api / version), and this interface returns the version identifier currently deployed on the server. Exemplarily, in the scenario of an e-commerce website, if the server has completed the function update of the product details page, its version identifier may be upgraded from v1.2.3 to v1.2.4, while the client locally still retains the old version identifier v1.2.3. At this time, the version difference can be quickly identified through string comparison.

[0041] It can be understood that the "comparison" operation uses strict equality verification. Specifically, the client performs a full-word match on the version string in the <meta> label returned by the server with the local one. If the two are inconsistent, it is determined that there is a version update. For example, when the user switches back from the email label page to the product management background page, the client detects that the version identifier has changed from v1.2.3 to v1.2.4, and then triggers the subsequent update prompt logic.

[0042] It should be noted that if the server interface request fails to return a valid version identifier due to network timeout or error, the client can degrade to using the local cached version for logical judgment, or ensure the reliability of version comparison according to a preset strategy (such as a retry mechanism) to avoid misjudgment caused by temporary failures.

[0043] Step 103: If the versions are inconsistent, pop up a window to prompt the user to choose whether to refresh the page or automatically perform a seamless data update operation.

[0044] In an embodiment of the present application, automatically performing a seamless data update operation specifically includes: obtaining the incremental data updated by the server through an asynchronous request; dynamically replacing the changed static resource links in the page DOM tree and maintaining the user's current operation focus; preloading the updated script file in the background and switching to the new version resource when the user jumps to the page next time.

[0045] In this embodiment, the "version inconsistency" means that there is a difference between the latest version identifier of the server and the local version identifier determined by the comparison logic in step 102. It can be understood that this difference indicates that a new version of the resource has been deployed online, and the user needs to be guided to perform an update operation to maintain data consistency.

[0046] Specifically, when a version inconsistency is detected, the client uses a native browser pop-up window (such as a confirm dialog box) or a custom modal box to display an update prompt to the user. Exemplarily, the pop-up window content includes a version update summary (such as "New order export function, performance optimized") and operation option buttons (such as "Refresh immediately", "Silent update", "Remind later"). When the user selects "Refresh immediately", location.reload(true) is called to forcefully reload the page by skipping the browser cache; when "Silent update" is selected, an incremental update process is triggered.

[0047] Furthermore, the silent data update operation includes the following sub-steps:

[0048] 1. Asynchronously request incremental data: Initiate a lightweight interface request (such as GET / api / update-diff?version=${currentVersion}) to the server to obtain a list of changed resources between the current version and the latest version (such as updated CSS / JS file paths, interface field change descriptions, etc.).

[0049] 2. Dynamically replace static resource links: Traverse the <script>和<link>标签，根据增量数据中的新资源URL替换旧版本链接。例如，将<script src＝"app.v1.js">替换为<scriptsrc＝"app.v2.js">，同时确保替换过程中保持用户当前操作焦点(如输入框光标位置、滚动条位置)不变。

[0050] 3.后台预加载与版本切换：在替换资源链接后，通过<link rel＝"preload">或动态创建<script>标签的方式预加载新版本脚本文件，但暂不执行新脚本。待用户触发页面跳转(如点击导航菜单)时，销毁旧版本资源并激活新版本脚本，实现无感知切换。

[0051] 需要说明的是，"默认操作逻辑”示例性地，若用户在预定义时间内(如30秒)未响应弹窗，则自动执行默认操作：对于版本更新弹窗，默认取消刷新并记录用户偏好(如存储userPrefersNoReload:true至localStorage)，后续可见性切换事件中可依据该偏好跳过弹窗提示；对于缓存恢复弹窗，默认清除缓存并跳转至网站首页，避免无效数据残留。

[0052] 可以理解的是，无感更新机制的核心在于避免中断用户当前操作。例如，用户正在填写长表单时，即使检测到版本更新，仍保持表单内容与焦点状态，仅后台预加载新资源，待用户提交表单后自然过渡至新版本页面。此举显著提升用户体验的连贯性，减少因强制刷新导致的数据丢失风险。

[0053] 步骤104、当页面可见性状态切换为hidden时，将当前页面操作节点状态序列化并存储至浏览器的持久化存储中。

[0054] 在本申请的一个实施例中，将当前页面操作节点状态序列化并存储至浏览器的持久化存储中，具体包括：捕获当前页面URL路径、路由参数及页面内用户输入的表单数据；将数据转换为JSON格式字符串，附加时间戳后加密存储至localStorage；在存储时标记缓存来源的浏览器标签页唯一标识符；其中，浏览器标签页唯一标识符用于区分多标签页场景下的缓存隔离。

[0055] 在本申请的一个实施例中，方法还包括：构建多标签页缓存隔离的实现机制，具体包括：在页面初始化时生成随机UUID作为标签页唯一标识符，并存储至sessionStorage；在序列化存储页面状态时，将UUID与页面缓存数据关联存储；在恢复缓存时，仅匹配当前标签页UUID对应的页面缓存数据，并自动清除其他标签页遗留缓存。

[0056] 在本实施例中，所述"页面可见性状态切换为hidden”指用户离开当前页面可视范围的操作，例如切换至其他标签页、最小化浏览器窗口或触发设备锁屏。可以理解的是，此时页面进入不可见状态，需立即捕获并持久化用户当前操作节点状态，以应对意外关闭场景下的数据恢复需求。

[0057] 具体地，所述"当前页面操作节点状态”包括以下核心数据：

[0058] 1.URL路径与路由参数：通过解析window.location.href获取完整页面路径及查询参数(如 / order-detail？id＝123)；

[0059] 2.用户输入的表单数据：遍历页面内所有表单元素(如<input>、<select>、<textarea>)，提取其name与value键值对；

[0060] 3.页面交互状态：例如折叠菜单的展开状态、数据分页的当前页码、表格排序规则等动态交互信息。

[0061] 示例性地，在企业管理系统场景中，用户正在编辑采购订单时临时切换至其他标签页，此时系统将捕获以下数据：

[0062]

[0063] 进一步地，本步骤的实现包括以下关键动作：

[0064] 序列化与加密：通过JSON.stringify()将数据转换为字符串，并附加时间戳(如"timestamp":1698765432100)标记缓存生成时间。为防止敏感数据泄露，采用浏览器原生加密API(如Crypto.subtle.encrypt())对字符串进行加密处理，生成密文后存储。

[0065] 多标签页隔离存储：根据权利要求4所述，在页面初始化时生成的标签页唯一标识符(UUID)，将加密后的数据与当前标签页UUID关联存储。例如，键名格式为cachePage_${uuid}，确保不同标签页的缓存数据独立存储、互不覆盖。

[0066] 持久化存储介质选择：使用localStorage作为持久化存储载体。可以理解的是，localStorage的特性允许数据在浏览器会话间保留，即使页面关闭或浏览器进程终止，仍可恢复至最后一次持久化状态。

[0067] 需要说明的是，所述UUID的生成与存储逻辑如下：在页面加载阶段，通过crypto.randomUUID()生成随机UUID；将UUID存储至sessionStorage中，键名为currentTabUUID；在序列化存储页面状态时，将该UUID作为数据隔离标识符。

[0068] 示例性地，用户同时打开两个标签页编辑不同采购订单，每个标签页生成独立UUID(如tab1_uuid与tab2_uuid)。当用户分别切换这两个标签页至不可见状态时，其操作状态将分别存储为cachePage_tab1_uuid与cachePage_tab2_uuid，从而实现多标签页场景下的缓存隔离。

[0069] 可以理解的是，附加时间戳的作用在于后续恢复操作时验证缓存有效期。例如，若用户超过预设有效期(如24小时)仍未恢复操作，系统可自动清除过期缓存，避免存储冗余数据或恢复陈旧状态导致业务逻辑冲突。

[0070] 步骤105、当检测到浏览器重新加载页面时，检查持久化存储中是否存在未恢复的缓存状态。

[0071] 在本实施例中，所述"浏览器重新加载页面”包括用户主动刷新页面、通过历史记录或书签重新访问，以及因浏览器崩溃或意外关闭后重新打开等场景。可以理解的是，此时需检查是否存在因上一次页面不可见状态(hidden)下持久化的未恢复缓存数据，以决定是否触发状态恢复流程。

[0072] 具体地，所述"检测缓存状态”的实现包括以下动作：

[0073] 1.初始化阶段遍历持久化存储：在页面加载完成事件(如DOMContentLoaded)触发后，调用localStorage.getItem()方法，以预设的键名前缀(如cachePage_)遍历所有持久化存储项。

[0074] 2.多标签页缓存匹配：根据标签页唯一标识符(UUID)机制，从sessionStorage中读取当前标签页的UUID，并筛选出键名包含该UUID的缓存数据。例如，若当前标签页UUID为tab1_uuid，则仅检查cachePage_tab1_uuid对应的缓存项，确保多标签页场景下缓存数据的精准匹配。

[0075] 3.缓存有效性校验：解析缓存数据中的时间戳字段，与当前系统时间比对，若超过预设有效期(如24小时)，则判定为过期数据并自动清除。示例性地，某用户因网络故障导致浏览器崩溃，24小时后重新访问网站时，系统检测到缓存时间戳已过期，直接清除无效数据，避免恢复陈旧状态。

[0076] 步骤106、若存在，则向用户弹窗提示选择是否恢复至缓存的操作节点，并根据用户选择执行页面重定向与状态反序列化操作或清除缓存。

[0077] 在本申请的一个实施例中，执行页面重定向与状态反序列化操作，具体包括：解析缓存数据中的时间戳，若超过预定义有效期则自动清除；在重定向至缓存URL前，向服务端验证该路径的当前可用性；若路径已失效，则跳转至兜底页面并提示用户重新操作；在反序列化表单数据时，校验字段类型与长度是否符合当前页面预期，丢弃非法数据字段。

[0078] 在本实施例中，若存在有效缓存数据，则触发权利要求8中定义的"向用户弹窗提示选择是否恢复至缓存的操作节点”。示例性地，弹窗内容可展示缓存生成时间、操作节点简要描述(如"未提交的采购订单草稿”)及操作选项("恢复”"放弃”)。用户选择"恢复”后，执行后续重定向与反序列化操作；选择"放弃”或未响应时，则清除缓存并跳转至默认页面。

[0079] 可以理解的是，所述"检测到浏览器重新加载页面”的逻辑需与页面初始化流程深度集成。例如，在单页应用(SPA)架构中，通过路由守卫(Route Guard)机制在每次路由跳转前检查缓存状态；而在传统多页应用(MPA)中，则通过全局脚本在页面加载时执行检查。

[0080] 示例性地，用户尝试恢复一周前的订单草稿时，系统首先校验时间戳已超有效期，直接清除缓存；若缓存有效但对应订单已被删除，则向服务端发起路径验证请求(如GET / purchase-order / validate / 456)，根据响应结果决定是否允许恢复或跳转至兜底页面。

[0081] 在本申请的一个实施例中，方法还包括：在服务端配置HTML文件的响应头；其中，HTML文件的响应头至少包括：Cache-Control:no-cache，no-store及Pragma:no-cache；对静态资源文件配置基于哈希值的强缓存策略，确保版本更新后资源URL路径自动失效。

[0082] 以上为本申请提出的方法实施例。基于同样的发明构思，本申请实施例还提供了一种网站页面缓存与刷新设备，其结构如图2所示。

[0083] 图2为本申请实施例提供的一种网站页面缓存与刷新设备内部结构示意图。如图2所示，设备包括：

[0084] 至少一个处理器201；

[0085] 以及，与至少一个处理器通信连接的存储器202；

[0086] 其中，存储器202存储有可被至少一个处理器执行的指令，指令被至少一个处理器201执行，以使至少一个处理器201能够：

[0087] 在网站入口文件中注册浏览器原生visibilitychange事件监听器，实时监测页面可见性状态；当页面可见性状态切换为visible时，向服务端请求当前部署资源的最新版本标识符，并与本地存储的版本标识符进行比对；若版本不一致，向用户弹窗提示选择是否刷新页面或自动执行无感数据更新操作；当页面可见性状态切换为hidden时，将当前页面操作节点状态序列化并存储至浏览器的持久化存储中；当检测到浏览器重新加载页面时，检查持久化存储中是否存在未恢复的缓存状态；若存在，则向用户弹窗提示选择是否恢复至缓存的操作节点，并根据用户选择执行页面重定向与状态反序列化操作或清除缓存。

[0088] 本申请的一些实施例提供的对应于图1的一种网站页面缓存与刷新的非易失性计算机存储介质，存储有计算机可执行指令，计算机可执行指令设置为：

[0089] 在网站入口文件中注册浏览器原生visibilitychange事件监听器，实时监测页面可见性状态；当页面可见性状态切换为visible时，向服务端请求当前部署资源的最新版本标识符，并与本地存储的版本标识符进行比对；若版本不一致，向用户弹窗提示选择是否刷新页面或自动执行无感数据更新操作；当页面可见性状态切换为hidden时，将当前页面操作节点状态序列化并存储至浏览器的持久化存储中；当检测到浏览器重新加载页面时，检查持久化存储中是否存在未恢复的缓存状态；若存在，则向用户弹窗提示选择是否恢复至缓存的操作节点，并根据用户选择执行页面重定向与状态反序列化操作或清除缓存。

[0090] 本申请中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于物联网设备和介质实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

[0091] 本申请实施例提供的系统和介质与方法是一一对应的，因此，系统和介质也具有与其对应的方法类似的有益技术效果，由于上面已经对方法的有益技术效果进行了详细说明，因此，这里不再赘述系统和介质的有益技术效果。

[0092] 本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

[0093] 本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和 / 或方框图来描述的。应理解可由计算机程序指令实现流程图和 / 或方框图中的每一流程和 / 或方框、以及流程图和 / 或方框图中的流程和 / 或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和 / 或方框图一个方框或多个方框中指定的功能的装置。

[0094] 这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和 / 或方框图一个方框或多个方框中指定的功能。

[0095] 这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和 / 或方框图一个方框或多个方框中指定的功能的步骤。

[0096] 在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入 / 输出接口、网络接口和内存。

[0097] 内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和 / 或非易失性内存等形式，如只读存储器(ROM)或闪存(flashRAM)。内存是计算机可读介质的示例。

[0098] 计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

[0099] 还需要说明的是，术语"包括”、"包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句"包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

[0100] 以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。< / script>

Claims

1. A method for caching and refreshing website pages, characterized in that The method includes: Register a browser-native visibilitychange event listener in the website entry file to monitor the page visibility status in real time; When the page visibility status switches to visible, request the latest version identifier of the currently deployed resources from the server and compare it with the version identifier stored locally; If the versions are inconsistent, pop up a window to prompt the user to choose whether to refresh the page or automatically perform a seamless data update operation; When the page visibility status switches to hidden, serialize the current page operation node status and store it in the browser's persistent storage; When it is detected that the browser reloads the page, check whether there is an unrecovered cached status in the persistent storage; If it exists, pop up a window to prompt the user to choose whether to restore to the cached operation node, and perform page redirection and status deserialization operations or clear the cache according to the user's choice.

2. The method for caching and refreshing a website page according to claim 1, characterized in that Request the version identifier of the currently deployed resources from the server and compare it with the version identifier stored locally, specifically including: Obtain the local version identifier by parsing the content of the meta tag in the HTML file; wherein, the local version identifier is a unique version identifier dynamically generated by the tool chain during the website construction phase; Initiate a lightweight interface request to the server to obtain the latest version identifier deployed by the server; Compare the local version identifier with the latest version identifier to determine whether the versions are consistent.

3. A method for caching and refreshing a website page according to claim 1, characterized in that, Serialize the current page operation node status and store it in the browser's persistent storage, specifically including: Capture the current page URL path, routing parameters, and form data entered by the user within the page; Convert the data into a JSON format string, encrypt it with a timestamp appended, and store it in localStorage; Mark the unique identifier of the browser tab where the cache comes from during storage; wherein, the unique identifier of the browser tab is used to distinguish cache isolation in the multi-tab scenario.

4. A method for caching and refreshing a website page according to claim 3, characterized in that, The method further includes: Build an implementation mechanism for multi-tab cache isolation, specifically including: Generate a random UUID as the unique identifier of the tab when the page is initialized and store it in sessionStorage; When serializing and storing the page status, associate and store the UUID with the page cache data; When restoring the cache, only match the page cache data corresponding to the current tab UUID and automatically clear the remaining caches of other tabs.

5. A method for caching and refreshing a website page according to claim 1, wherein Automatically perform a seamless data update operation, specifically including: Obtain the incremental data updated by the server through an asynchronous request; Dynamically replace the changed static resource links in the page DOM tree and keep the user's current operation focus; Preload the updated script file in the background and switch to the new version of the resource when the user jumps to the page next time.

6. A method for caching and refreshing a website page according to claim 1, characterized in that, The method further includes: Configure the response header of the HTML file on the server; wherein, the response header of the HTML file at least includes: Cache-Control: no-cache, no-store and Pragma: no-cache; Configure a strong caching policy based on hash values for static resource files to ensure that the resource URL path becomes invalid automatically after the version is updated.

7. A method for caching and refreshing a website page according to claim 1, characterized in that, The method further includes: Define the logic for prompting the user with a pop-up window, specifically including: Display the version update log or a brief description of the cache recovery operation in the pop-up window; If the user does not respond to the pop-up window within the predefined time, the default operation is automatically executed; wherein, the default operation includes: for the version update pop-up window, the default is to cancel the refresh and record the user's preferences; for the cache recovery pop-up window, the default is to clear the cache and jump to the website home page.

8. A method for caching and refreshing a website page according to claim 1, characterized in that, Execute page redirection and state deserialization operations, specifically including: Parse the timestamp in the cache data and automatically clear it if it exceeds the predefined validity period; Before redirecting to the cache URL, verify the current availability of the path with the server; If the path has become invalid, jump to the fallback page and prompt the user to operate again; When deserializing form data, verify whether the field type and length meet the expectations of the current page, and discard illegal data fields.

9. A website page caching and refreshing device, characterized in that, The device includes: At least one processor; And a memory communicatively connected to the at least one processor; Wherein, the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute a method for caching and refreshing a website page as described in any one of claims 1-8.

10. A non-volatile computer storage medium for website page caching and refreshing, storing computer-executable instructions, characterized in that, When the computer-executable instructions are executed, a method as described in any one of claims 1-8 is implemented.

Images