An application processing method and apparatus, a storage medium, and an electronic device

Abstract

This specification discloses an application processing method, apparatus, storage medium, and electronic device. The method includes: loading an application connector component in the host environment corresponding to the host application in response to a resource access request from the host application; triggering the initialization mounting logic of the application connector component to obtain web page document content and parse runtime proxy configuration information from the web page document content; performing pre-interception and interface takeover on the request initiation logic of the host browser's native global asynchronous network request interface in the host environment based on the runtime proxy configuration information; after the global asynchronous network request interface is in the interface takeover state, loading the corresponding application resources based on the resource entry address of the target business sub-application using a micro-frontend architecture engine; and performing target address redirection processing on the network request initiated by the target business sub-application based on the runtime proxy configuration information through the global asynchronous network request interface in the interface takeover state.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and in particular to an application processing method, apparatus, storage medium, and electronic device. Background Technology

[0002] In the evolution of the enterprise web application ecosystem, enterprises typically have a large number of existing hosted applications built on early application development platforms. These existing applications often carry core business lines and need to maintain long-term stable operation and iteration. Meanwhile, with the continuous upgrading of front-end architecture technologies, new business requirements often tend to be developed using next-generation lightweight application development platforms to pursue better page performance and agile delivery experiences. This leads to a core technical challenge for enterprise information systems: how to smoothly and seamlessly integrate new application pages developed independently based on new technology stacks into existing legacy applications that lack modern underlying architecture capabilities, in order to provide users with a unified and consistent business experience.

[0003] Currently, common solutions for cross-application integration in the industry mainly include system refactoring and migration, inline frame nesting, and module federation based on build tools. However, these traditional solutions all have significant engineering limitations: system refactoring requires extremely high R&D and testing costs, and directly modifying old systems can easily trigger online risks; inline frame nesting creates independent browser runtime contexts, which can easily lead to the user interface layer being obscured, blank screens, and difficulties in cross-domain communication, severely disrupting the user experience; while micro-frontend technologies such as module federation usually require strong coupling between the host application and sub-applications during the code building and compilation phases, making them completely unsuitable for existing old applications whose build and release processes cannot be easily changed. Therefore, there is an urgent need in this field for an integration solution that can achieve cross-technology stack page assembly in a non-intrusive and low-cost manner. Summary of the Invention

[0004] This specification provides an application processing method, apparatus, storage medium, and electronic device, the technical solutions of which are as follows: Firstly, this specification provides an application processing method applied to an electronic device running a host application, the method comprising: In response to a resource access request for a host application, an application connector component is loaded in the host environment corresponding to the host application, and the initialization mounting logic of the application connector component is triggered to obtain web page document content and parse runtime proxy configuration information from the web page document content. Based on the runtime proxy configuration information, pre-interception and interface takeover operations are performed on the request initiation logic of the host browser's native global asynchronous network request interface in the host environment. After the global asynchronous network request interface is in the interface takeover state, the micro frontend architecture engine loads the corresponding application resources according to the resource entry address of the target business sub-application, and performs target address redirection processing on the network requests initiated by the target business sub-application based on the runtime proxy configuration information through the global asynchronous network request interface in the interface takeover state. The host application is developed based on the first application development platform, and the target business sub-application is a lightweight integrated sub-application developed for the host application on the second application development platform.

[0005] Secondly, this specification provides an application processing apparatus, the apparatus comprising: The loading module is used to respond to resource access requests for the host application, load the application connector component in the host environment corresponding to the host application, trigger the initialization mounting logic of the application connector component, obtain the web page document content, and parse the runtime proxy configuration information from the web page document content. The runtime module is used to perform pre-interception and interface takeover operations on the request initiation logic of the host browser's native global asynchronous network request interface in the host environment, based on the runtime proxy configuration information. The running module is used to load the corresponding application resources based on the resource entry address of the target business sub-application according to the micro-frontend architecture engine after the global asynchronous network request interface is in the interface takeover state, and to perform target address redirection processing on the network requests initiated by the target business sub-application based on the runtime proxy configuration information through the global asynchronous network request interface in the interface takeover state. The host application is developed based on the first application development platform, and the target business sub-application is a lightweight integrated sub-application developed for the host application on the second application development platform.

[0006] Thirdly, this specification provides a computer storage medium storing at least one instruction adapted for loading by a processor and executing method steps of one or more embodiments of this specification.

[0007] Fourthly, this specification provides a computer program product storing at least one instruction adapted to be loaded by a processor and to execute the method steps of one or more embodiments of this specification.

[0008] Fifthly, this specification provides an electronic device that may include: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to execute the method steps of one or more embodiments of this specification.

[0009] The beneficial effects of the technical solutions provided in some embodiments of this specification include at least the following: In one or more embodiments of this specification, an application connector component is non-intrusively loaded into the host environment to dynamically parse runtime proxy configuration information embedded in the web page document. Before the target business sub-application is loaded, the underlying pre-interception and takeover operations are performed on the host browser's native global asynchronous network request interface based on this configuration information. Using a micro-frontend architecture engine with on-demand wake-up, the target business sub-application is rendered to an isolated container. Transparent target address redirection is performed on network communications initiated by the sub-application through the underlying network interface in the takeover state. This solves the problems of window fragmentation and cross-domain communication difficulties caused by traditional inline frame (iframe) nesting schemes when enterprise information systems iterate across generations and platforms. It also overcomes the engineering implementation barriers of conventional micro-frontend solutions that force existing legacy host systems to undergo underlying code modification and have strong dependency coupling. It can dynamically empower existing host systems lacking modern underlying architectures to load incremental business applications in a lightweight manner with zero modification and zero intrusion, reducing the reconstruction cost and online risks of cross-generational systems. Meanwhile, by taking over the browser's native network interface in advance and using a dynamic rule redirection mechanism, any network communication initiated by the target business sub-application within the sandbox can be transparently proxied to the designated gateway by the underlying layer. This completely eliminates the need for intrusive modifications to the original business code of the sub-application and the burden of complex cross-domain processing. In addition, the on-demand detection loading and targeted isolated rendering of the micro-frontend underlying engine not only effectively avoids the repeated fetching of redundant execution libraries to improve the performance of the first screen rendering, but also builds a strict security boundary between the physical view layer and the memory runtime layer. This eliminates the global namespace pollution and cascading style conflicts that may be caused by heterogeneous systems running on the same screen and from the same origin. As a result, a high-quality integration experience is achieved within a single browser window, where the visuals of the old and new systems are perfectly integrated and the underlying communication flows seamlessly. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in this specification or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a schematic diagram of an application processing system provided in this manual; Figure 2 This is a flowchart illustrating an application processing method provided in this manual; Figure 3 This is a flowchart illustrating a parsing process provided in this manual; Figure 4 This is a schematic diagram of the structure of an application processing device provided in this specification; Figure 5 This is a schematic diagram of the structure of an electronic device provided in this specification. Detailed Implementation

[0012] The technical solutions in this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this specification.

[0013] In the description of this specification, it should be understood that the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. In the description of this specification, it should be noted that, unless otherwise expressly specified and limited, "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices. Those skilled in the art can understand the specific meaning of the above terms in this specification based on the specific circumstances. Furthermore, in the description of this specification, unless otherwise stated, "multiple" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship.

[0014] The present specification will now be described in detail with reference to specific embodiments.

[0015] Please see Figure 1 This is a schematic diagram of an application processing system provided in this specification. Figure 1 As shown, the application processing system may include at least a client cluster and a service platform 100.

[0016] The client cluster may include at least one client, such as Figure 1 As shown, it specifically includes client 1 corresponding to user 1, client 2 corresponding to user 2, ..., client n corresponding to user n, where n is an integer greater than 0.

[0017] Each client in a client cluster can be an electronic device with communication capabilities, including but not limited to: wearable devices, handheld devices, personal computers, tablets, in-vehicle devices, smartphones, computing devices, or other processing devices connected to a wireless modem. Electronic devices may have different names in different networks, such as: user equipment, access terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, electronic device, wireless communication device, user agent or user device, cellular phone, cordless phone, personal digital assistant (PDA), and electronic devices in 5G networks or future evolved networks.

[0018] The service platform 100 can be a standalone server device, such as a rack-mount, blade, tower, or cabinet-type server device, or a workstation, mainframe, or other hardware device with strong computing power; or it can be a server cluster composed of multiple servers. The servers in the service cluster can be composed in a symmetrical manner, wherein each server is functionally and hierarchically equivalent in the transaction chain, and each server can provide services independently. The independent provision of services can be understood as not requiring the assistance of other servers.

[0019] In one or more embodiments of this specification, the service platform 100 can establish a communication connection with at least one client in the client cluster, and complete the data interaction during application processing based on the communication connection.

[0020] It should be noted that the service platform 100 establishes a communication connection with at least one client in the client cluster via a network for interactive communication. This network can be a wireless network or a wired network. Wireless networks include, but are not limited to, cellular networks, wireless LANs, infrared networks, or Bluetooth networks. Wired networks include, but are not limited to, Ethernet, universal serial bus (USB), or controller area networks. In one or more embodiments of the specification, technologies and / or formats including Hyper Text Markup Language (HTML), Extensible Markup Language (XML), etc., are used to represent data exchanged over the network (such as target compressed packets). Furthermore, conventional encryption technologies such as Secure Socket Layer (SSL), Transport Layer Security (TLS), Virtual Private Network (VPN), and Internet Protocol Security (IPsec) can be used to encrypt all or some links. In other embodiments, customized and / or dedicated data communication technologies can be used to replace or supplement the aforementioned data communication technologies.

[0021] The application processing system embodiments provided in this specification and the application processing methods described in one or more embodiments belong to the same concept. The execution subject corresponding to the application processing methods involved in one or more embodiments of this specification can also be the electronic device corresponding to the client, which is determined based on the actual application environment. The implementation process of the application processing system embodiments can be found in the following method embodiments, which will not be repeated here.

[0022] based on Figure 1 The following is a detailed description of the application processing methods provided by one or more embodiments of this specification, as illustrated in the schematic diagram of the scenario.

[0023] Please see Figure 2 This document provides a flowchart illustrating an application processing method according to one or more embodiments of this specification. This method can be implemented using a computer program and can run on an application processing device based on the von Neumann architecture. The computer program can be integrated into an application or run as a standalone utility application. The application processing device can be an electronic device.

[0024] Specifically, the application's processing methods include: S102: In response to a resource access request for the host application, load the application connector component in the host environment corresponding to the host application, trigger the initialization mounting logic of the application connector component to obtain web page document content and parse runtime proxy configuration information from the web page document content; Resource access request: refers to a Hypertext Transfer Protocol request initiated by the host environment running on the user terminal (such as a web browser, a web container embedded in the client, etc.) to a remote server to obtain specific page resources, script files, or style streams.

[0025] Initialization mounting logic: refers to the loading and rendering preparation procedures automatically executed by the front-end component (application connector component) at the beginning of its lifecycle. It typically includes, but is not limited to: reading environment variables, initializing internal state, and executing the code process of actually mounting the component's virtual node and rendering it into the host document object model (DOM) tree.

[0026] Web page document content: refers to the Hypertext Markup Language (HTML) structured text stream sent to the terminal after the server responds to the resource access request. In addition to the basic skeleton of the page, this text stream also contains script identifiers, style metadata and various business configuration texts for components to read.

[0027] An application connector component refers to a lightweight front-end logic unit or page proxy entity that is non-intrusively introduced by the host application (e.g., as a regular static script or web page fragment). This component typically does not directly carry specific business window display logic, but rather acts as a runtime bridge for cross-platform or cross-technology stack system integration. Internally, it highly encapsulates environment state detection, dynamic parsing of runtime proxy configurations, pre-interception and takeover of browser-level global asynchronous network request interfaces, and core control logic for micro-frontend architecture engine scheduling. This allows the host environment to dynamically and non-intrusively assemble, run, and manage heterogeneous target business sub-applications within a shared-origin document context without requiring modifications to the legacy host architecture. An example is the Smart Connector / MicroAppWrapper component.

[0028] Runtime proxy configuration information refers to a set of structured network routing control policy data dynamically extracted and deserialized from web page documents sent by the server by the application connector component during the runtime phase. This configuration information typically includes key communication parameters such as request matching rules for triggering interception (e.g., specific prefix identifiers of request Uniform Resource Locators), target gateway communication addresses mapped to the matching rules, and cross-domain processing policies. As the core data basis for the underlying redirection logic of the system, it guides the global asynchronous network request interfaces that have been taken over to perform precise target address replacement before actually initiating network communication, thereby achieving transparent proxying and dynamic routing distribution of underlying network requests without modifying any native communication code of the target business sub-application.

[0029] To illustrate, when a user terminal (i.e., an electronic device) running the host application sends a resource access request for the host application, the server returns web page document content containing the host page skeleton and the links leading to the application connector component. The terminal's browser downloads and loads the application connector component in the host environment and displays the smart connector interface corresponding to the application connector component. During the display process, when the application connector component triggers its initial mounting logic, it calls the browser's native document object model operation interface (such as document.querySelectorAll) to read the currently loaded web page document content. The component traverses the node tree of the web page document, accurately compares and matches specific script tags with preset type attribute identifiers (e.g., with the custom attribute type="tern-app-config"). Subsequently, it extracts the node content (usually a format string) wrapped inside the specific script tag and calls the data deserialization parsing function to convert it into a structured environment configuration object, thereby completing the parsing of runtime proxy configuration information and storing it in memory or the global context for later use.

[0030] For example, to facilitate understanding, we will use the integration of an "incremental performance appraisal module" into a company's "existing human resources (HR) management system" as an example.

[0031] When an employee clicks the "Performance Appraisal" menu in a browser on an electronic device, the browser sends a resource access request to the server. The HTML document returned by the server contains the basic navigation bar code of the legacy system, along with a lightweight JavaScript file called "Application Connector Component." It also implicitly injects a proxy configuration string for the "Performance Appraisal Module" within the HTML tags (e.g., a rule mapping the / perf-api path to a dedicated performance server).

[0032] When the browser executes the script of the "application connector component," the component instantly triggers its own initialization and mounting logic (e.g., triggering the `componentDidMount` lifecycle method of a React component). Before the actual "performance evaluation module" screen is rendered, the component quickly scans the downloaded HTML source code, accurately locates the pre-injected proxy configuration string, and uses a JSON parsing method to convert it into a configuration object in memory. At this point, the connector component has parsed all the underlying rules required for subsequent interception and proxying of network requests in a very short time, fully preparing for the subsequent complete takeover of network communication.

[0033] Optionally, to enable those skilled in the art to better understand the complete technical chain of the present invention, it should be noted that before executing step S102, the method of the present invention may also rely on application assembly and connector generation logic pre-executed on the server side (i.e., the first application development platform side). This pre-assembly stage aims to complete the data association and environment preparation between heterogeneous platforms, and the specific execution process is as follows: 1) Expanding Platform Resource Types and Retrieving Application List Execution Phase: In the resource creation interface of the first application development platform (i.e., the development backend of existing host applications, such as a low-code page building platform), a new resource creation option pointing to external micro-applications (i.e., target business sub-applications) is pre-configured. In response to the triggering operation of this new option by developers or system administrators, the first application development platform initiates a cross-platform data request call to the second application development platform (i.e., the R&D and hosting platform for incremental applications). By calling the specified application programming interface (API), the list data of the target business sub-applications already published in the second application development platform is obtained. The list data returned by the interface includes the core metadata of the target business sub-applications, including but not limited to: application display name, application unique identifier (ID), and the network operating environment type to which the application belongs (e.g., office network environment or public internet environment). The first application development platform displays the obtained list data on the interface in a tree structure or list format for developers to select and associate.

[0034] 2) Dynamic Calculation and Concatenation of Resource Entry Address Execution Phase: Upon receiving the specific target business sub-application selected by the developer on the interface, the underlying system of the first application development platform will execute the dynamic generation logic of the resource address. The system will obtain the global runtime environment variables of the current host application to be deployed (such as test environment, pre-production environment, or production environment), and combine them with the network runtime environment type of the selected target business sub-application and the application's unique identifier to dynamically calculate and generate a unique resource entry address. Specifically, the system maintains a basic path mapping table. By using the global runtime environment variables and the network runtime environment type as a composite index key, the corresponding basic network path is matched from the mapping table. Then, the basic network path is concatenated with the application's unique identifier to obtain a Uniform Resource Locator (i.e., the resource entry address) that accurately points to the actual build product of the target business sub-application.

[0035] 3) Automated Generation of Application Connector Components and Their Configuration Carrier Execution Phase: After completing the above association and address generation, the first application development platform does not require developers to manually write code. Instead, it automatically creates a specific host page that cannot be directly edited by ordinary users based on the built-in page template through the background automated engineering pipeline. The core physical entity of this specific host page is a pre-encapsulated front-end proxy middleware entity (such as a React front-end component). The system integrates the aforementioned dynamically generated resource entry address, cross-domain gateway address, and network request routing proxy rules, and uses the formatted string (such as JSON format) as business application configuration text, pre-embedded and injected into the specified document node (such as a specific type of script tag) of this specific host page.

[0036] At this point, the specific host page automatically generated by the server-side system, which embeds the front-end proxy middleware entity and business application configuration text, constitutes the interface corresponding to the aforementioned application connector component. This application connector component is statically hosted on a server or content delivery network (CDN), in a system ready state, awaiting access from end users of electronic devices.

[0037] After completing the above pre-assembly logic, when the end user of the electronic device actually operates the device, the system enters the core runtime takeover stage of this manual, that is, it begins to execute steps S102 to S106. S104: Based on the runtime proxy configuration information, perform pre-interception and interface takeover operations on the request initiation logic of the host browser's native global asynchronous network request interface in the host environment. Global asynchronous network request interfaces: These refer to standard network communication application programming interfaces natively provided by the host browser kernel and exposed under global mount points (such as the window object). They mainly include Hypertext Transfer Protocol request interfaces (such as XMLHttpRequest) used to implement traditional asynchronous JavaScript and Extensible Markup Language technologies, as well as next-generation global fetch interfaces based on Promise mechanisms (such as fetch).

[0038] Request initiation logic: refers to the core methods or execution sequences in the above interfaces that actually trigger the popping of network requests from the stack (such as the open and send methods of an XMLHttpRequest instance, or the behavior of directly calling the fetch() function).

[0039] Pre-interception and interface takeover operations refer to replacing the browser's default network request handling logic with a custom interception proxy module using advanced front-end programming features (such as object property descriptors or proxy design patterns) before the target business sub-application is actually loaded and run. This takeover operation ensures that all network requests generated in the subsequent application must first pass through the custom interception proxy module before being formally handed over to the browser's underlying network communication thread.

[0040] To illustrate, after obtaining the parsed data from the webpage document, the application connector component first executes the configuration extraction logic (corresponding to the proxy configuration extraction function in the project implementation). Based on the global runtime environment variables of the current host environment (such as the `window.runtimeDeployEnv` property of the underlying object), it accurately extracts the specific network proxy rules applicable to the current deployment environment from the parsed data. Subsequently, and before the target business sub-application is actually loaded, the application connector component calls the preset custom interception proxy function (such as the `proxyAjax` and `fetchProxy` functions in the project code) to forcibly rewrite and hijack the underlying call logic of the host browser's native Hypertext Transfer Protocol request interface (XMLHttpRequest) and global fetch interface. In this takeover state, when the hijacked native interface is triggered by the business code to initiate a network request, the rewritten interception proxy function will prioritize capturing this action and automatically check whether the Uniform Resource Locator (URL) of the current request matches the specific route prefix (such as the ` / api` identifier) ​​set in the network proxy rules. If the system determines that the prefix matches, the intercepting proxy function will, before the request data packet actually leaves the browser's network layer, forcibly and dynamically replace the original request target address with the gateway communication address mapped in the network proxy rule (e.g., a specific front-end gateway domain name), and automatically handle Cross-Origin Resource Sharing (CORS) restrictions in the underlying request header. Because the above proxy configuration is dynamically extracted, and the entire interface takeover process is completed before the sub-application is loaded, it ensures that all subsequent network requests initiated within the sub-application can be correctly and transparently proxyed and redirected without requiring any intrusive modifications to the target business sub-application's own code logic.

[0041] S106: After the global asynchronous network request interface is in the interface takeover state, the micro frontend architecture engine loads the corresponding application resources according to the resource entry address of the target business sub-application, and performs target address redirection processing on the network request initiated by the target business sub-application based on the runtime proxy configuration information through the global asynchronous network request interface in the interface takeover state. The host application is developed based on a first application development platform, and the target business sub-application is a lightweight integrated sub-application developed for the host application on a second application development platform. Micro-frontend architecture engine: refers to a core scheduling library or runtime container used to coordinate, load, unload, and isolate multiple independent frontend business applications within the host browser environment. This engine is responsible for providing independent script execution sandboxes and style isolation mechanisms for sub-applications, preventing global variable pollution or style conflicts between heterogeneous applications, such as the Qiankun engine.

[0042] Resource entry address: refers to the Uniform Resource Locator (URL) that is dynamically calculated and generated during the pre-application assembly stage, and accurately points to the static resources (including pre-build artifacts such as Hypertext Markup Language documents, Cascading Style Sheets, and script files) of the target business sub-application.

[0043] Destination address redirection processing: refers to the technical action of dynamically rewriting and routing the target attributes of the original request data packet by the underlying interception code after network communication is intercepted. It aims to transparently convert requests for the original relative path or cross-domain path into direct requests for a specific gateway server, and in the process, complete the request header information for cross-domain restriction processing types.

[0044] As an illustration, after the global asynchronous network request interface is in the interface takeover state, the application connector component (such as the MicroAppWrapper component) first performs probe detection in the global namespace of the current host environment to determine whether the global object of the micro-frontend architecture engine (such as the window.qiankun object) exists. If the object is detected to exist, it indicates that the host environment or other related scripts have already imported the engine, and the system directly reuses the current instance; if the detection result is that it does not exist, the system triggers an asynchronous resource fetching instruction to dynamically load the execution library file (such as the qiankun library) corresponding to the micro-frontend architecture engine. This on-demand loading detection mechanism effectively avoids hard dependencies on the underlying code of the host environment, thereby improving the backward compatibility of the system. Subsequently, the system calls the micro-application loading application programming interface (such as the loadMicroApp API) built into the micro-frontend architecture engine. Based on the pre-generated dynamically constructed target business sub-application resource entry address (i.e., EntryURL), it accurately retrieves the front-end build artifacts of the target business sub-application (such as the Muse sub-application) actually selected by the user, and renders the retrieved application resources to a pre-defined document object model isolation container (such as one with a specific identifier) ​​within the host page. (In the tag).

[0045] After the target business sub-application is successfully mounted and running, when it initiates a low-level network request according to its own business logic, the request will be seamlessly intercepted by the global asynchronous network request interface in a pre-managed state. The low-level takeover logic performs target address redirection processing on the request based on the runtime proxy configuration information, realizing transparent proxying of network communication. In addition, to ensure the security and stability of system operation, when the application connector component triggers a lifecycle unmounting action, the system will strictly execute the micro-application's unmounting instruction (such as calling the microApp.unmount() method) and simultaneously unwrite the rewrite state of the aforementioned hijacked global asynchronous network request interface (API), restoring its original default execution logic. This cleanup mechanism ensures that the entire specific host page can be cleanly unmounted, guaranteeing that after the micro-frontend application exits, it will not cause any pollution or negative impact on the original functionality and global state of the host application.

[0046] This specification describes a method that non-intrusively loads an application connector component into the host environment to dynamically parse runtime proxy configuration information embedded in web page documents. Before the target business sub-application loads, it performs low-level pre-interception and takeover operations on the host browser's native global asynchronous network request interface based on this configuration information. Using a micro-frontend architecture engine with on-demand wake-up, the target business sub-application is rendered into an isolated container. Transparent target address redirection is then performed on network communications initiated by the sub-application through the low-level network interface in takeover mode. This solves the problems of view fragmentation and cross-domain communication difficulties caused by traditional inline frame (iframe) nesting schemes when enterprise information systems iterate across generations and platforms. It also overcomes the engineering implementation barriers of conventional micro-frontend solutions that force existing legacy host systems to undergo low-level code modification and have strong dependency coupling. It can dynamically empower existing host systems lacking modern underlying architectures to load incremental business applications in a lightweight manner with zero modification and zero intrusion, reducing the reconstruction cost and online risks of cross-generational systems. Meanwhile, by taking over the browser's native network interface in advance and using a dynamic rule redirection mechanism, any network communication initiated by the target business sub-application within the sandbox can be transparently proxied to the designated gateway by the underlying layer. This completely eliminates the need for intrusive modifications to the original business code of the sub-application and the burden of complex cross-domain processing. In addition, the on-demand detection loading and targeted isolated rendering of the micro-frontend underlying engine not only effectively avoids the repeated fetching of redundant execution libraries to improve the performance of the first screen rendering, but also builds a strict security boundary between the physical view layer and the memory runtime layer. This eliminates the global namespace pollution and cascading style conflicts that may be caused by heterogeneous systems running on the same screen and from the same origin. As a result, a high-quality integration experience is achieved within a single browser window, where the visuals of the old and new systems are perfectly integrated and the underlying communication flows seamlessly.

[0047] Optionally, before specifically executing the micro-frontend architecture engine to load the corresponding application resources based on the resource entry address of the target business sub-application, in order to avoid hard dependencies on the underlying code of the host environment, this embodiment of the invention may also refer to the following underlying engine wake-up and loading mechanism, which can be executed in the following manner: 1) Wake up the micro-frontend architecture engine, that is, before loading the application resources of the target business sub-application, detect whether there is an instance object of the micro-frontend architecture engine in the global namespace of the host environment; 2) If the detection result is that the resource does not exist, an asynchronous resource retrieval instruction is triggered, and the execution library file corresponding to the micro frontend architecture engine is loaded into the host environment and initialized through dynamic script injection.

[0048] To illustrate, firstly, before loading the application resources of the target business sub-application, the system will wake up the micro-frontend architecture engine. Specifically, the system executes probe detection logic, that is, it detects whether there is an instance object of the micro-frontend architecture engine in the global namespace of the host environment (for example, it detects whether the corresponding engine variable has been mounted under the current browser window object).

[0049] Secondly, a differentiated initialization strategy is executed based on the detection results: If the detection result indicates that the architecture has not been introduced in the current host environment (old system), an asynchronous resource fetch command is triggered, which is performed via dynamic script injection (e.g., dynamically creating and inserting resources). <script>标签），将所述微前端架构引擎对应的执行库文件实时加载至所述宿主环境中并进行初始化。

[0050] 若探测结果为存在，表明宿主环境或其他关联脚本已提前引入了该引擎，则直接复用当前全局命名空间中的实例对象，跳过确定"探测结果为不存在”后的重复加载步骤。

[0051] 在本说明书中，采用上述唤醒与按需探测机制的有益效果在于：一方面，通过动态脚本注入的方式按需加载微前端架构引擎，彻底解耦了存量宿主环境与底层架构的硬性代码依赖，使得即便是不具备现代化前端架构的老旧宿主系统，也能以"零改造、零侵入”的轻量化方式获得加载增量业务应用的能力，极大降低了跨代际系统的集成成本；另一方面，通过前置的全局实例探测，系统能够智能复用已有的运行环境，有效避免了引擎执行库文件的重复拉取与重复初始化，这不仅显着降低了网络带宽消耗、提升了目标业务子应用的首屏渲染速度，更从根本上杜绝了多次引入同一底层架构库可能引发的全局命名空间污染与运行时冲突，从而保障了异构系统集成环境的高效与稳定。

[0052] 可选的，S106中具体执行所述基于微前端架构引擎依据目标业务子应用的资源入口地址加载对应的应用资源，包括：1）调用初始化完成后的所述微前端架构引擎内的微应用加载应用程序编程接口；微前端架构引擎指在用户终端浏览器内存中驻留的，用于协调、装配、隔离及卸载多个异构前端业务应用的底层核心调度库。其内部封装了完整的应用生命周期状态机、全局变量沙箱（如基于Proxy 的隔离机制）以及样式隔离模块。

[0053] 微应用加载应用程序编程接口指由上述引擎对外暴露的、用于触发特定业务子应用实例化与挂载装配过程的核心控制函数（例如实际工程实现中的loadMicroApp接口）。该接口不仅接收子应用的资源定位参数，还负责在底层开辟出供子应用独立运行的隔离上下文环境。

[0054] 示意性的，在完成所述微前端架构引擎的探针探测与按需加载逻辑后，电子设备系统即确认该引擎已在宿主环境的全局命名空间中处于初始化完成的就绪状态。此时，应用连接器组件作为宿主环境中的代理模块，会在主线程中主动触发并执行调用初始化完成后的所述微前端架构引擎内的微应用加载应用程序编程接口的动作。具体而言，电子设备在控制执行该调用指令时，会将前置装配阶段动态拼接生成的目标业务子应用的资源入口地址，以及宿主页面内预先划定的文档对象模型（DOM）隔离容器的挂载节点标识作为调用参数，一并传递给该应用程序编程接口。随着该接口被成功触发，系统的运行时控制流正式从宿主应用侧的连接器组件，移交至微前端架构引擎内部的生命周期管理模块。引擎底层在接收到调用指令与传入参数后，会立即在内存中为即将到来的目标业务子应用构建出一套独立的虚拟全局执行上下文（即运行沙箱），并启动对宿主环境原有全局变量与底层方法的快照备份机制，从而在网络请求真正发往远端拉取增量资源之前，提前在宿主浏览器内部筑起一道严密的安全隔离墙，确保后续增量业务代码的执行绝对不会污染或覆盖老旧宿主系统的原生运行逻辑。

[0055] 2）依据所述资源入口地址拉取所述目标业务子应用的前端构建产物，并将解析后的所述前端构建产物定向渲染至宿主应用页面内预先设定的文档对象模型隔离容器中。

[0056] 前端构建产物：指目标业务子应用在第二应用开发平台（如增量应用研发平台）中经过编译、打包与压缩后，所生成的具备直接可执行能力的静态资源集合；通常以超文本标记语言（HTML）文档作为基础入口载体，并内嵌或外链了相应的级联样式表（CSS）与核心业务逻辑的脚本文件（JavaScript）。

[0057] 文档对象模型隔离容器：指在宿主应用页面结构中预先规划并占位的一个特定超文本标记语言节点（例如带有特定标识属性的标签，如代码中的）。该容器作为增量业务界面的物理挂载锚点，承载了底层的样式作用域隔离（Scoped CSS）或影子节点（Shadow DOM）机制，用以确保容器内部渲染的任何样式变动均不会外溢至宿主全局。

[0058] 示意性的，在所述微前端架构引擎内的微应用加载应用程序编程接口被成功触发后，电子设备系统底层的调度模块随即进入资源拉取与解析装配阶段。具体而言，电子设备系统通过所述微前端架构引擎底层会接管网络获取动作，依据传入的所述目标业务子应用的资源入口地址，向远端内容分发网络或业务服务器发起针对性的静态资源拉取请求。在成功获取所述目标业务子应用的前端构建产物（即作为入口的HTML文档及其关联资源）后，引擎内部的超文本解析器并不会直接将这些文本粗暴地注入当前页面，而是对该构建产物进行深度结构树解析，将其剥离为独立的样式流、文档节点树以及可执行的脚本代码。随后，执行严格的定向渲染与挂载逻辑：将解析后重构的子应用文档节点树，精准地插入至宿主应用页面内预先设定的文档对象模型隔离容器中；同时，剥离出的脚本代码被引导至上一步构建好的安全运行沙箱内独立执行，而样式流则在经过前缀包裹或作用域重写等隔离化处理后，再挂载至该隔离容器所在的局部作用域内。通过上述解析与定向渲染的闭环动作，最终在用户浏览器的单一视窗内，将异构且独立开发的目标业务子应用完美嵌合进存量宿主应用的基础界面中，并在物理视图层与内存运行层均维持了严格的安全边界，实现了互不干扰的轻量级无缝集成效果。

[0059] 可选的，如图3所示，图3是一种解析处理的流程示意图，具体执行所述获取网页文档内容并从所述网页文档内容解析运行时代理配置信息，可以参考以下方式：S202：在所述应用连接器组件挂载于所述宿主环境的文档对象模型期间，读取当前宿主应用网页的超文本标记语言文档内容；文档对象模型指宿主浏览器将超文本标记语言（HTML）文档解析后在内存中构建的树状结构应用程序编程接口。其允许运行在浏览器中的脚本动态访问和更新文档的内容、结构与样式。

[0060] 挂载期间：指所述应用连接器组件在前端框架的生命周期中，其虚拟节点实例刚被创建并准备或刚刚插入到宿主环境真实的文档对象模型树中的这一特定时间窗口。

[0061] 示意性的，利用了前端组件生命周期的特定阶段来实现无感的数据截获。当宿主浏览器的渲染引擎加载到所述应用连接器组件的脚本代码时，该组件即被初始化。在所述应用连接器组件挂载于所述宿主环境的文档对象模型期间（例如在React组件的componentDidMount生命周期钩子触发时），该组件并不向远端服务器发起任何额外的异步数据请求，而是直接将检索聚焦转向自身所处的运行环境，然后系统调用浏览器原生的文档操作接口（如特定的节点查询选择器），以极低的性能开销，在内存中直接读取当前宿主应用网页已经下载完毕的超文本标记语言文档内容。

[0062] S204：从读取的所述超文本标记语言文档内容中，提取出服务端预先植入的业务应用配置文本，并基于所述业务应用配置文本确定所述运行时代理配置信息。

[0063] 业务应用配置文本：指在前置的系统装配阶段，由服务端随宿主页面的原始HTML流一并下发，并预先隐蔽植入于页面特定节点（如自定义脚本标签或元数据标签）内部的、未经反序列化的原始字符串数据。

[0064] 示意性的，在完成对当前宿主页面文档内容的读取后，系统立即启动内置的配置提取与编译逻辑。系统通过遍历读取到的所述超文本标记语言文档的节点树，或者利用预设的正则表达式与属性选择器，从海量的文档元素中精准提取出服务端预先植入的业务应用配置文本（例如，精确定位并提取出带有type="tern-app-config"属性的特定<script>标签内部包裹的纯文本串）。在成功剥离出该配置文本后，系统调用内置的数据反序列化解析函数（如JSON.parse），对该格式化字符串执行严格的类型转换与结构化反序列化操作，将其从静态的字符串形态转换为内存中可被程序直接读取与寻址的结构化环境配置对象。最终，系统将该配置对象显式挂载至宿主环境的全局上下文（如window对象下的特定命名空间）中，并以此作为后续指导所有网络拦截与路由转发动作的所述运行时代理配置信息。

[0065] S202-S204示例，当用户访问存量系统的一个菜单页时，服务端返回的HTML文档中已经通过上述S202-S204的方式塞入了一段类似<script type="tern-app-config">{"proxyRules": {" / api": "https: / / gateway.com"}}< / script> The connector component scans the HTML source code the moment the page is rendered (mounted), parses the JSON string, and converts it into a real configuration object that is stored in memory.

[0066] This specification describes a mechanism that directly reads and parses pre-embedded configuration text from the current host webpage document during the mounting of the application connector component. This transforms the traditional micro-frontend architecture's reliance on secondary asynchronous network requests for configuration acquisition into direct output of the hypertext and self-parsing of the local document. This completely eliminates the configuration loading gap caused by network latency, effectively avoiding the risk of missed underlying network requests or race conditions caused by the target business sub-application loading the configuration information before it does. This ensures the absolute pre-emption and operational safety of interface takeover and route redirection logic. At the same time, this mechanism allows the server to complete the environment configuration simply by performing lightweight static text injection when distributing the hypertext markup language document. There is no need to develop and maintain additional cross-domain configuration data interfaces, which greatly reduces the backend transformation cost of legacy systems and perfectly matches the zero-dependency, non-intrusive, lightweight integration effect between heterogeneous systems.

[0067] In one feasible implementation, specifically performing step S204 involves extracting the pre-embedded business application configuration text from the read Hypertext Markup Language document content, including: S302: Traverse the node tree of the Hypertext Markup Language document to match specific script tags with preset type attribute identifiers; A node tree refers to a hierarchical tree-like data structure formed by the host browser after parsing a Hypertext Markup Language document, in which each hypertext tag, text paragraph, or attribute is mapped to an independent node on the tree structure.

[0068] Preset type attribute identifier: refers to a non-standard or custom media type declaration that is manually set in a specific script tag (e.g., setting...). <script>标签的原生属性type="text / javascript"修改为自定义的type="tern-app-config"）。该标识的主要作用是阻断浏览器内核的默认脚本执行引擎，使其仅将该标签视为一种纯粹的数据静态载体。

[0069] S304：将所述特定脚本标签内的节点内容作为包括网络代理规则的格式化字符串，以得到业务应用配置文本。

[0070] 格式化字符串指按照特定数据交换格式（如JavaScript对象简谱，即JSON格式）排版和转义后的纯文本字符序列，其内部包裹了用于指引网络请求重定向的具体网络代理规则。

[0071] 示意性的，先执行步骤S302中的节点树遍历与标识匹配逻辑，通过应用连接器组件调用宿主浏览器原生的文档查询接口（如document.querySelectorAll或深度优先的节点遍历算法），以当前宿主网页文档的根节点为起点，遍历所述超文本标记语言文档的节点树。在遍历过程中，系统将目标锁定为特定的超文本标签元素（即<script>标签），并逐一检视这些标签的属性集，以精确匹配具有所述预设类型属性标识的特定脚本标签。由于该特定脚本标签声明了非标准的媒体类型，宿主浏览器的JavaScript引擎在页面初始化阶段会自动忽略该标签，不会尝试将其内部的文本作为可执行代码进行编译，从而将其安全地静置于节点树中等待被组件主动唤醒读取。

[0072] 在成功定位并匹配到该特定脚本标签后，随即执行步骤S304中的文本抽取逻辑，通过应用连接器组件调用原生节点内容读取属性（如textContent或innerHTML），直接从所述特定脚本标签的内部边界中提取出由服务端预先生成的节点内容。系统不改变该节点内容的原有字符排布，而是直接将所述特定脚本标签内的节点内容作为包括网络代理规则的格式化字符串进行内存暂存，从而完整无损地得到了所述业务应用配置文本，为紧随其后的数据反序列化与内存对象转换提供了准确的原始数据底座。

[0073] 在本说明书中，采用上述基于特定脚本标签遍历与属性匹配的提取机制，巧妙利用了浏览器内核对非标准类型脚本标签只解析DOM结构而不执行内部代码的原生底层特性，将包含核心网络代理规则的配置信息安全、隐蔽地封装在超文本标记语言文档的特定节点中；这一技术手段不仅彻底避免了配置数据被浏览器引擎误认作业务逻辑代码执行而引发的语法错误或跨站脚本安全漏洞，还能够利用浏览器原生提供的高效节点查询接口实现快速精准定位与提取，从而在保障微前端集成环境绝对安全的前提下，将配置解析步骤的性能开销降至最低。

[0074] 可选的，具体执行S204中所述基于所述业务应用配置文本确定所述运行时代理配置信息，包括：S402：调用数据反序列化解析函数，对作为所述业务应用配置文本的所述格式化字符串执行反序列化操作，生成结构化的环境配置对象；数据反序列化解析函数指宿主环境内置的或由第三方引入的，用于将特定格式的字节流或文本序列（如JavaScript对象简谱，JSON格式字符串）逆向转换为编程语言原生数据结构的底层解析算法库。

[0075] 结构化的环境配置对象指经过反序列化处理后，驻留于浏览器系统内存中的、具备层级关系与键值对（Key-Value）映射特性的动态数据实体，其内部包含了具体的网络代理路由表与跨域网关标识。

[0076] S404：将所述环境配置对象显式挂载并注入至所述宿主环境的全局上下文对象中，并将注入后的所述环境配置对象作为所述运行时代理配置信息。

[0077] 全局上下文对象指宿主浏览器执行环境中处于作用域链顶端的顶层对象（例如浏览器环境下的window对象或globalThis对象），挂载于该对象下的属性与方法具备全局可见性，可被当前同源文档内的所有脚本跨作用域直接访问。

[0078] 示意性的，在完成对预设脚本标签内配置文本的提取后，执行步骤S402，通过应用连接器组件在内存中调用宿主环境内置的数据反序列化解析函数（例如原生的JSON.parse()方法），以作为业务应用配置文本的格式化字符串为输入源，对其执行严格的词法分析与反序列化操作。在此过程中，解析引擎会校验该字符串的格式合法性，剥离转义字符，并依据文本中定义的层级逻辑，在系统内存中重新分配空间，从而将原本线性的、仅用于网络传输与超文本承载的静态字符串，动态生成为程序可直接进行属性寻址与读写操作的结构化的环境配置对象。

[0079] 完成内存对象的实例化后，执行步骤S404的全局注入逻辑，为了确保后续被接管的底层网络请求接口（如前述的XMLHttpRequest 或fetch API）能够跨越函数作用域的物理隔离，毫无阻碍地读取到这些代理规则，应用连接器组件不将该配置对象作为局部变量封闭在自身组件内部，而是利用宿主环境的顶层应用程序编程接口，将环境配置对象显式挂载并注入宿主环境的全局上下文对象中（例如，在window对象下开辟一个名为__TERN_APP_CONFIG__的专属只读命名空间属性，并将配置对象赋值于此）。完成上述全局注入动作后，系统即确认网络路由规则已在宿主环境中完成初始化就绪，并将注入后的环境配置对象正式作为运行时代理配置信息，为步骤S104中执行的前置拦截操作提供确切的数据路由指引。

[0080] 在本说明书中，过反序列化操作实现了配置数据从超文本传输安全形态向内存高速读写形态的转换，使得底层网络拦截逻辑在比对路由前缀时可以利用哈希映射实现快速键值寻址，提升了网络请求代理的执行效率；此外，将配置对象显式挂载至全局上下文对象中，巧妙地利用了浏览器的原生作用域特性，实现了配置数据提取模块与底层网络接口接管模块之间的深度解耦，两者无需进行复杂的跨组件状态传递，仅需通过约定的全局命名空间即可完成高频的数据通信，从而大幅提升了微前端连接器组件内部代码的健壮性与可维护性。

[0081] 可选的，具体执行S104中所述在所述宿主环境中对宿主浏览器原生的全局异步网络请求接口的请求发起类逻辑执行前置拦截操作与接口接管操作，可以参考以下方式：S502：在所述宿主应用对应的目标业务子应用加载之前，获取所述宿主环境下宿主浏览器原生的全局异步网络请求接口中的超文本传输协议请求接口以及全局获取接口；超文本传输协议请求接口指宿主浏览器内核原生提供的一种传统的应用程序编程接口（即XMLHttpRequest或简称XHR），主要用于在后台与服务器交换数据，是早期异步无刷新页面（AJAX）技术的核心底层依赖。

[0082] 全局获取接口指现代浏览器环境标准中引入的基于期约机制的新一代网络通信接口（即fetchAPI），其暴露在全局作用域中，用于替代传统的XHR 发起跨网络资源的异步获取请求。

[0083] 示意性的，在具体执行接口接管动作时，先执行步骤S502中的接口获取与时机控制逻辑。可以理解的时间窗口的把控在此步骤中至关重要，系统必须严格确保在所述宿主应用对应的目标业务子应用被实际加载并运行之前，抢先接管网络控制权。此时，电子设备通过应用连接器组件的底层探针会在内存中检索并获取所述宿主环境下宿主浏览器原生的全局异步网络请求接口，具体包括提取挂载于全局对象（如window）下的所述超文本传输协议请求接口（XMLHttpRequest）的构造函数原型引用，以及所述全局获取接口（fetch）的函数指针引用。为了保证在需要时能够恢复浏览器的默认网络行为，系统会在内存的私有变量中对这些原生接口的原始引用进行安全缓存（备份）。

[0084] S504：利用预设代理函数重写所述超文本传输协议请求接口以及所述全局获取接口的请求发起类底层调用逻辑，以基于重写后的所述请求发起类底层调用逻辑截获所述宿主环境内产生的网络请求体，所述预设代理函数包括前置拦截操作与接口接管操作对应的代理函数。

[0085] 预设代理函数：指在应用连接器组件内部预先封装好的一段包含条件判断、地址匹配与重定向转发逻辑的包装代码。该函数在内存中充当着请求关卡的角色，负责在真实的底层网络发包动作执行前对其进行审查和篡改。

[0086] 请求发起类底层调用逻辑指浏览器内核中真正触发网络数据包构建与发送的函数或方法。对于超文本传输协议请求接口（XMLHttpRequest），其对应于原型链上的open（初始化请求参数）和send（发送请求载荷）方法；对于全局获取接口（fetch），其对应于该接口自身的函数调用执行体。

[0087] 网络请求体（Request Payload / Body）：指目标业务子应用在调用上述接口时传入的所有网络通信参数集合，不仅包括统一资源定位符（URL）、请求方法（如GET / POST），还涵盖了请求头、跨域凭证以及实际传输的数据载荷。

[0088] 示意性的，在完成对宿主原生接口的获取与安全备份后，即启动执行步骤S504中的重写与截获逻辑。针对全局获取接口（fetch），直接将宿主环境全局对象下的fetch属性指针，重新指向系统内部预先定义的第一预设代理函数。当目标业务子应用随后调用fetch发起网络通信时，执行流会进入该第一预设代理函数内部。在该第一代理函数内首先执行前置拦截操作，即提取入参中的目标统一资源定位符与网络请求体信息，阻止其直接向宿主浏览器底层的网络线程派发，随后执行接口接管操作即在内存中保持该请求的期约为挂起状态，等待后续的路由规则比对与网关地址替换逻辑执行完毕后，再调用先前备份的原生fetch接口将篡改后的请求真实发出。

[0089] 同步地，针对超文本传输协议请求接口利用动态语言的原型链机制执行更为深度的重写逻辑。此时，电子设备系统并不改变该接口的构造函数本身，而是将其原型对象（prototype）上的open方法与send方法替换为第二预设代理函数。具体而言，当业务子应用实例化一个请求对象并调用open方法时，重写后的代理函数会首先截获请求方法类型与目标统一资源定位符，并将其隐式缓存在当前实例的自定义属性中；当子应用进一步调用send方法准备发送数据时，重写后的发送代理函数被触发，系统借此彻底截获包含了数据载荷的完整网络请求体。

[0090] 通过上述分别针对两种主流原生网络接口的底层调用逻辑重写，应用连接器组件在宿主环境中实现了严密的全局拦截网，确保了无论目标业务子应用内部采用何种上层网络请求库（如axios、jQuery 等），只要其最终依赖浏览器的原生接口向外发包，其产生的任何网络请求体都将被重写后的底层调用逻辑无一遗漏地前置截获，并交由预设代理函数进行统一的接管与调度。

[0091] 可选的，具体执行所述基于所述运行时代理配置信息对所述目标业务子应用发起的网络请求进行目标地址重定向处理，包括：S602：当监听到所述目标业务子应用发起实际网络请求时，比对所述实际网络请求的请求统一资源定位符与所述运行时代理配置信息中设定的网络请求规则前缀是否匹配；监听指应用连接器组件中预设的代理函数处于激活并挂载于底层原生接口（如已被重写的fetch、XMLHttpRequest）上的待命状态，一旦业务代码调用网络发包指令，该状态即被触发。

[0092] 实际网络请求指目标业务子应用内部的业务逻辑代码在运行时真正生成、并进入底层网络调用栈的请求实体。

[0093] 请求统一资源定位符（Request URL）指上述实际网络请求中所携带的、用于指示应用原始预期资源获取路径的字符串序列（如 / api / v1 / user / info）。

[0094] 网络请求规则前缀指前置解析并驻留于全局内存中的所述运行时代理配置信息中包含的路由识别标识（如 / api / v1 / 或特定正则表达式），用于作为触发后续网关地址替换动作的匹配基准。

[0095] 示意性的，在应用连接器组件完成底层网络接口的接管布置后，即进入持续的监听与比对状态。当监听到目标业务子应用发起实际网络请求时，处于拦截状态的代理函数（如重写后的fetch包装函数或XMLHttpRequest的open代理方法）会首先将浏览器的原生发包动作予以挂起，并立即从截获的该实际网络请求上下文中，提取出对应的所述请求统一资源定位符。随后系统读取暂存于宿主全局上下文中的所述运行时代理配置信息，并启动内置的路由匹配引擎。该匹配引擎会遍历代理配置信息中预设的代理规则映射表，将提取出的请求统一资源定位符与表中的所述网络请求规则前缀进行逐一比对。

[0096] 在具体比对实现上，系统既可以采用严格的字符串前缀匹配算法（如判断URL 是否以特定的字符串切片开头），也可以应用更为复杂的正则表达式引擎进行动态模式匹配。

[0097] 在此比对过程中，执行判决分支逻辑：若匹配引擎遍历完所有规则后判定当前请求的统一资源定位符与任何网络请求规则前缀均不匹配，则直接调用预先备份的原生底层网络接口将该请求原样放行，让其按照宿主浏览器默认的网络策略发往原相对路径所在的服务器；而一旦判定比对匹配则立即将该请求标记为"待重定向状态”，并将其推入下一步的地址篡改执行流S604中。

[0098] S604：若判定比对匹配，则在所述实际网络请求发出前，将所述实际网络请求的原请求目标地址替换为所述运行时代理配置信息中对应的网关通信地址。

[0099] 实际网络请求发出前指请求体已在内存中构建完毕，但尚未通过操作系统底层套接字（Socket）发送至网络驱动层的临界时间点。在JavaScript 环境下，通常对应于原生接口执行流被预设代理函数挂起并拦截的区间。

[0100] 原请求目标地址指目标业务子应用在业务代码中书写的原始资源定位符（通常为相对路径，如 / api / v1 / data），该地址在未处理前默认指向宿主应用的域名。

[0101] 网关通信地址指在运行时代理配置信息中明确定义的、具备跨域访问权限的增量业务后端入口（如https: / / new-gateway.com），该地址通常包含协议头、域名及可能的端口号。

[0102] 示意性的，在步骤S602判定所述请求统一资源定位符与所述网络请求规则前缀匹配后，所述应用连接器组件内部的路由分发模块立即介入。在所述实际网络请求真正通过物理链路发出之前，系统执行如下地址重构逻辑：首先，系统解析提取出所述运行时代理配置信息中与当前匹配前缀相对应的所述网关通信地址；随后，系统执行字符串重组动作，将所述实际网络请求的原请求目标地址中与规则前缀重合或冲突的部分进行剔除或保留处理，并将其剩余的业务路径片段无缝拼接至所述网关通信地址之后。

[0103] 例如，若原请求目标地址为 / api / v1 / user，匹配规则前缀为 / api / v1 / ，映射的网关通信地址为https: / / gw.service.com，则系统会将原地址动态替换为全新的绝对路径https: / / gw.service.com / api / v1 / user。

[0104] 在完成上述统一资源定位符的动态改写后，同步更新网络请求体中的主机名（Host）等关键请求头信息，以确保请求能够顺利通过远端网关的安全校验。最终，所述预设代理函数将篡改后的、指向全新网关地址的请求体重新注入浏览器底层的异步通信引擎中，从而完成实际的网络发包动作。整个替换过程对于上层业务子应用而言是完全透明的，实现了请求流的物理重定向。

[0105] 在本说明书中，通过在网络协议栈的最底层执行静默重定向，彻底解决了异构系统集成中最为棘手的跨域资源共享与网关路由分发问题。该机制允许增量业务子应用维持其原有的相对路径开发习惯，无需针对不同的部署环境硬编码复杂的后端地址，从而实现了一套代码，多处集成。此外，这种实时替换逻辑极大地增强了系统的灵活性，运维人员只需通过更新服务端的配置文本即可动态调整所有子应用的后端通信链路，而无需重新打包或发布前端业务代码，提升了大规模集成环境下的系统鲁棒性与运维效率。

[0106] 进一步的，所述将所述实际网络请求的原请求目标地址替换为所述运行时代理配置信息中对应的网关通信地址之后，还包括：1）在所述实际网络请求中添加跨域限制处理类型的请求头信息；示意性的，由于所述实际网络请求的原请求目标地址被替换为跨域的所述网关通信地址，为了确保重定向后的请求能够通过目标服务器或网关的安全校验与跨域资源共享（CORS）策略，在实际网络请求发出前的拦截窗口期内，通过应用连接器组件会自动执行请求头增强操作，从而系统会在截获的网络请求体中，动态注入一组预设的跨域限制处理类型的请求头信息，（例如，添加Access-Control-Allow-Origin、特定的Client-ID、或用于身份鉴权的Authorization字段）。此外还根据运行时代理配置信息，自动修正请求体中的Host字段和Origin字段，使其与目标网关通信地址保持一致。

[0107] 2）在监测到所述应用连接器组件触发生命周期卸载动作时，解除对所述超文本传输协议请求接口以及所述全局获取接口的重写状态，以恢复所述宿主环境的网络请求默认执行逻辑。

[0108] 生命周期卸载动作指前端组件在其所属框架（如Vue、React 或原生微前端容器）中执行的销毁流程。通常发生于用户切换主应用路由、关闭当前功能页或手动移除微应用插件时，对应于引擎内部的unmount或destroyed钩子函数。

[0109] 重写状态指宿主环境全局对象中的原生接口（XMLHttpRequest和fetch）已被指向预设代理函数（拦截器）的受控状态。

[0110] 默认执行逻辑指宿主浏览器环境在未经任何脚本篡改前，由浏览器内核（如提供的标准化、原生的异步网络请求处理机制。

[0111] 示意性的，不仅关注增量应用的加载，同样关注宿主环境在应用退出后的状态完整性。在应用连接器组件运行期间，系统会持续监测所述应用连接器组件的生命周期状态。

[0112] 一旦监测到所述应用连接器组件触发生命周期卸载动作（例如，监测到子应用容器节点从文档对象模型中移除的事件），系统立即启动环境还原逻辑：先从连接器组件初始化阶段创建的私有受保护变量中，提取出预先备份的所述宿主环境下宿主浏览器原生的全局异步网络请求接口的原始引用（即备份的原生fetch指针及XMLHttpRequest原型方法），后执行覆盖式还原操作。具体而言，系统将宿主全局上下文（window对象）下的fetch属性重新指向备份的原生fetch引用，并同步将XMLHttpRequest.prototype上的open与send等方法还原为备份的原生方法。 通过解除对上述两个核心通信接口的重写状态，移除了先前布设的所有拦截钩子。此后，宿主环境产生的任何网络请求将不再经过预设代理函数的比对与重定向逻辑，而是直接进入宿主环境的网络请求默认执行逻辑。

[0113] 在本说明书中，通过在拦截层面自动补全跨域校验所需的关键信息，消除了因域名变更导致的浏览器安全拦截风险。这使得目标业务子应用在无需感知跨域细节的前提下，能够顺利与异构后端进行安全通信，极大地降低了微前端集成过程中的服务端配置复杂度。以及在组件卸载后，宿主环境的网络请求会立即恢复为浏览器的默认执行逻辑，不会留存任何长期运行的拦截脚本或内存污染。保障了宿主应用其他原生模块的运行安全性，避免了多套系统交替运行时的逻辑冲突。

[0114] 下面将结合图4，对本说明书提供的应用处理装置进行详细介绍。需要说明的是，图4所示的应用处理装置，用于执行本说明书图2~图3所示实施例的方法，为了便于说明，仅示出了与本说明书相关的部分，具体技术细节未揭示的，请参照本说明书图2~图3所示的实施例。

[0115] 请参见图4，其示出本说明书的应用处理装置的结构示意图。该应用处理装置1可以通过软件、硬件或者两者的结合实现成为用户电子设备的全部或一部分。根据一些实施例，该应用处理装置1包括加载模块11、运行模块12，具体用于：加载模块11，用于响应于针对宿主应用的资源访问请求，在所述宿主应用对应的宿主环境中加载应用连接器组件，触发所述应用连接器组件的初始化挂载逻辑，以获取网页文档内容并从所述网页文档内容解析运行时代理配置信息；运行模块12，用于基于所述运行时代理配置信息，在所述宿主环境中对宿主浏览器原生的全局异步网络请求接口的请求发起类逻辑执行前置拦截操作与接口接管操作；所述运行模块12，用于在所述全局异步网络请求接口处于接口接管状态后，基于微前端架构引擎依据目标业务子应用的资源入口地址加载对应的应用资源，并通过处于所述接口接管状态的全局异步网络请求接口，基于所述运行时代理配置信息对所述目标业务子应用发起的网络请求进行目标地址重定向处理；其中，所述宿主应用基于第一应用开发平台开发，所述目标业务子应用为在第二应用开发平台中针对所述宿主应用所开发的轻量集成类子应用。

[0116] 需要说明的是，上述实施例提供的应用处理装置在执行应用处理方法时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的应用处理装置与应用处理方法实施例属于同一构思，其体现实现过程详见方法实施例，这里不再赘述。

[0117] 上述本说明书序号仅仅为了描述，不代表实施例的优劣。

[0118] 本说明书还提供了一种计算机存储介质，所述计算机存储介质可以存储有多条指令，所述指令适于由处理器加载并执行如上述图2~图3所示实施例的所述应用处理方法，具体执行过程可以参见图2~图3所示实施例的具体说明，在此不进行赘述。

[0119] 本说明书还提供了一种计算机程序产品，该计算机程序产品存储有至少一条指令，所述至少一条指令由所述处理器加载并执行如上述图2~图3所示实施例的所述应用处理方法，具体执行过程可以参见图2~图3所示实施例的具体说明，在此不进行赘述。

[0120] 请参考图5，为本说明书实施例提供的一种电子设备的结构方框图。本说明书中的电子设备可以包括一个或多个如下部件：处理器1010、存储器1020、输入装置1030、输出装置1040和总线1050。处理器1010、存储器1020、输入装置1030和输出装置1040之间可以通过总线1050连接。

[0121] 处理器1010可以包括一个或者多个处理核心。处理器1010利用各种接口和线路连接整个电子设备内的各个部分，通过运行或执行存储在存储器1020内的指令、程序、代码集或指令集，以及调用存储在存储器1020内的数据，执行电子设备的各种功能和处理数据。可选地，处理器1010可以采用数字信号处理（digital signal processing，DSP）、现场可编程门阵列（field－programmable gate array，FPGA）、可编程逻辑阵列（programmable logicArray，PLA）中的至少一种硬件形式来实现。处理器1010可集成中心处理器（centralprocessing unit，CPU）、图像处理器（graphics processing unit，GPU）和调制解调器等中的一种或几种的组合。其中，CPU主要处理操作系统、用户界面和应用程序等；GPU用于负责显示内容的渲染和绘制；调制解调器用于处理无线通信。可以理解的是，上述调制解调器也可以不集成到处理器1010中，单独通过一块通信芯片进行实现。

[0122] 存储器1020可以包括随机存储器（random Access Memory，RAM），也可以包括只读存储器（read-only memory，ROM）。可选地，该存储器1020包括非瞬时性计算机可读介质（non-transitory computer-readable storage medium）。存储器1020可用于存储指令、程序、代码、代码集或指令集。

[0123] 其中，输入装置1030用于接收输入的指令或数据，输入装置1030包括但不限于键盘、鼠标、摄像头、麦克风或触控设备。输出装置1040用于输出指令或数据，输出装置1040包括但不限于显示设备和扬声器等。在本说明书实施例中，输入装置1030可以为温度传感器，用于获取电子设备的运行温度。输出装置1040可以为扬声器，用于输出音频信号。

[0124] 除此之外，本领域技术人员可以理解，上述附图所示出的电子设备的结构并不构成对电子设备的限定，电子设备可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。比如，电子设备中还包括射频电路、输入单元、传感器、音频电路、无线保真（wireless fidelity，WIFI）模块、电源、蓝牙模块等部件，在此不再赘述。

[0125] 在本说明书实施例中，各步骤的执行主体可以是上文介绍的电子设备。可选地，各步骤的执行主体为电子设备的操作系统。操作系统可以是安卓系统，也可以是IOS系统，或者其它操作系统，本说明书实施例对此不作限定。

[0126] 在图5的电子设备中，处理器1010可以用于调用存储器1020中存储的程序，并执行以实现如本说明书各个方法实施例所述的应用处理方法。

[0127] 本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体或随机存储记忆体等。

[0128] 需要说明的是，本说明书实施例所涉及的信息（包括但不限于用户设备信息、用户个人信息等）、数据（包括但不限于用于分析的数据、存储的数据、展示的数据等）以及信号，均为经用户授权或者经过各方充分授权的，且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。例如，本说明书中涉及的特征、数据以及信息等都是在充分授权的情况下获取的。

[0129] 以上所揭露的仅为本说明书较佳实施例而已，当然不能以此来限定本说明书之权利范围，因此依本说明书权利要求所作的等同变化，仍属本说明书所涵盖的范围。< / script>

Claims

1. An application processing method, applied to an electronic device running a host application, the method comprising: In response to a resource access request for a host application, an application connector component is loaded in the host environment corresponding to the host application, and the initialization mounting logic of the application connector component is triggered to obtain web page document content and parse runtime proxy configuration information from the web page document content. Based on the runtime proxy configuration information, pre-interception and interface takeover operations are performed on the request initiation logic of the host browser's native global asynchronous network request interface in the host environment. After the global asynchronous network request interface is in the interface takeover state, the micro frontend architecture engine loads the corresponding application resources according to the resource entry address of the target business sub-application, and performs target address redirection processing on the network requests initiated by the target business sub-application based on the runtime proxy configuration information through the global asynchronous network request interface in the interface takeover state. The host application is developed based on the first application development platform, and the target business sub-application is a lightweight integrated sub-application developed for the host application on the second application development platform.

2. The method according to claim 1, wherein obtaining webpage document content and parsing runtime proxy configuration information from the webpage document content includes: During the process of the application connector component being mounted on the document object model of the host environment, the hypertext markup language document content of the current host application webpage is read; From the read Hypertext Markup Language document content, the pre-embedded business application configuration text on the server is extracted, and the runtime proxy configuration information is determined based on the business application configuration text.

3. The method according to claim 2, wherein extracting the pre-embedded business application configuration text from the read Hypertext Markup Language document content includes: Traverse the node tree of the Hypertext Markup Language document to match specific script tags with preset type attribute identifiers; The node content within the specific script tag is used as a formatted string including network proxy rules to obtain the business application configuration text.

4. The method according to claim 3, wherein determining the runtime agent configuration information based on the business application configuration text includes: The data deserialization parsing function is invoked to perform a deserialization operation on the formatted string, which serves as the business application configuration text, to generate a structured environment configuration object. The environment configuration object is explicitly mounted and injected into the global context object of the host environment, and the injected environment configuration object is used as the runtime proxy configuration information.

5. The method according to claim 1, wherein performing pre-interception and interface takeover operations on the request initiation logic of the host browser's native global asynchronous network request interface in the host environment includes: Before the target business sub-application corresponding to the host application is loaded, obtain the Hypertext Transfer Protocol request interface and the global acquisition interface in the host browser's native global asynchronous network request interface under the host environment; The underlying call logic of the request initiation class of the Hypertext Transfer Protocol request interface and the global acquisition interface is rewritten using a preset proxy function, so as to intercept the network request body generated in the host environment based on the rewritten underlying call logic of the request initiation class. The preset proxy function includes proxy functions corresponding to the pre-interception operation and the interface takeover operation.

6. The method according to claim 5, wherein the step of redirecting the network request initiated by the target business sub-application based on the runtime proxy configuration information includes: When the target business sub-application initiates an actual network request, compare whether the request Uniform Resource Locator of the actual network request matches the network request rule prefix set in the runtime proxy configuration information; If a match is found, the original target address of the actual network request is replaced with the corresponding gateway communication address in the runtime proxy configuration information before the actual network request is sent.

7. The method according to claim 6, further comprising, after replacing the original target address of the actual network request with the corresponding gateway communication address in the runtime proxy configuration information: Add cross-origin restriction handling type request header information to the actual network request; Furthermore, when the application connector component is detected to have triggered a lifecycle uninstallation action, the rewrite state of the Hypertext Transfer Protocol Request interface and the Global Acquisition interface is released to restore the default execution logic of network requests in the host environment.

8. The method according to claim 1, before loading the corresponding application resources based on the resource entry address of the target business sub-application using the micro-frontend architecture engine, further comprising: Wake up the micro-frontend architecture engine and detect whether there is an instance of the micro-frontend architecture engine in the global namespace of the host environment; If the detection result is that the resource does not exist, an asynchronous resource retrieval instruction is triggered, and the execution library file corresponding to the micro-frontend architecture engine is loaded into the host environment and initialized through dynamic script injection.

9. The method according to claim 8, wherein the loading of corresponding application resources based on the resource entry address of the target business sub-application by the micro-frontend architecture engine includes: After initialization, the micro-application loading application programming interface within the micro-frontend architecture engine is invoked; The front-end build artifacts of the target business sub-application are retrieved based on the resource entry address, and the parsed front-end build artifacts are then rendered into a pre-defined document object model isolation container within the host application page.

10. An application processing apparatus for use in an electronic device running a host application, the apparatus comprising: The loading module is used to respond to resource access requests for the host application, load the application connector component in the host environment corresponding to the host application, trigger the initialization mounting logic of the application connector component, obtain the web page document content, and parse the runtime proxy configuration information from the web page document content. The runtime module is used to perform pre-interception and interface takeover operations on the request initiation logic of the host browser's native global asynchronous network request interface in the host environment, based on the runtime proxy configuration information. The running module is used to load the corresponding application resources based on the resource entry address of the target business sub-application according to the micro-frontend architecture engine after the global asynchronous network request interface is in the interface takeover state, and to perform target address redirection processing on the network requests initiated by the target business sub-application based on the runtime proxy configuration information through the global asynchronous network request interface in the interface takeover state. The host application is developed based on the first application development platform, and the target business sub-application is a lightweight integrated sub-application developed for the host application on the second application development platform.

11. A computer storage medium storing a plurality of instructions adapted for loading by a processor and executing the steps of the method as claimed in any one of claims 1 to 9.

12. A computer program product storing at least one instruction, the at least one instruction being loaded by a processor and executing the steps of the method as described in any one of claims 1 to 9.

13. An electronic device, comprising: A processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to execute the steps of the method as described in any one of claims 1 to 9.

Images