时空漫步者的日记

用户态和内核态的定位用户态和内核态的区分是在操作系统层面进行的。这两种状态是操作系统为了安全和管理而设计的。在操作系统中，内核态（Kernel Mode）是运行操作系统程序、操作硬件的状态，具有最高权限；而用户态（User Mode）是运行用户程序的状态，其权限受到限制。当用户程序需要操作系统帮助完成某些它没有权力和能力完成的工作时，就会通过系统调用陷入到内核态，由操作系统来完成相应的工作。 用户态用户态也被称为用户模式，是指应用程序的运行状态。在这种模式下，应用程序拥有有限的系统资源访问权限，只能在操作系统划定的特定空间内运行。用户态下运行的程序不能直接访问硬件设备或执行特权指令，所有对硬件的访问都必须通过操作系统进行。在用户态下，应用程序通过系统调用来请求操作系统提供的服务。例如，文件操作、网络通信等都需要通过系统调用来实现。当应用程序发出系统调用时，会触发上下文切换，将CPU的控制权交给操作系统内核，进入内核态。 内核态内核态也被称为内核模式或特权模式，是操作系统内核的运行状态。处于内核态的CPU可以执行所有的指令，访问所有的内存地址，拥有最高的权限。内核态下运行的程序可以访问系 ...

1234567891011121314151617181920212223242526272829303132333435363738io +- github +- xxyopen +- novel +- NovelApplication.java -- 项目启动类 | +- core -- 项目核心模块，包括各种工具、配置和常量等 | +- common -- 业务无关的通用模块 | | +- exception -- 通用异常处理 | | +- constant -- 通用常量 | | +- req -- 通用请求数据格式封装，例如分页请求数据 | | +- resp -- 接口响应工具及响应数据格式封装 | | +- util -- 通用工具 | | ...

12345import {getCurrentInstance, ComponentInternalInstance} from 'vue'const update = getCurrentInstance() as ComponentInternalInstance | nullupdate!.proxy!.$forceUpdate()

12345678<iframe id="reportIframe" frameborder="0" scrolling="auto" style="width: 100%; height: 100%" :src=""/>

運用 postMessage 解決 iframe 與父層溝通的問題 问题描述当在iframe的父级监听iframe中的内容时候，如果内嵌的路由与父级的源不一致，会出现跨域问题。出现如下报错信息： 12345const iframe = document.querySelector("iframe");iframe.onload = () => { const iframeInner = iframe.contentWindow; console.log(iframeInner);}; 12Uncaught DOMException: Failed to read a named property 'document' from 'Window': Blocked a frame with origin "http://localhost:1024" from accessing a cross-origin frame. at eval ( 基於同源政策，如果 ...

ftp_manager.py 123456789101112131415161718192021222324252627282930313233343536373839404142434445from ftplib import FTPclass FtpManager: host = "" username = "" password = "" def __init__(self): """连接到 FTP 服务器""" self.ftp = FTP(self.host) # 替换为你的 FTP 服务器地址 self.ftp.login(user=self.username, passwd=self.password) # 替换为你的用户名和密码 def list_files(self): """列举目录中的所有文件""" ...

manager – 通用业务处理层，对第三方平台封装、对 Service 层通用能力的下沉以及对多个 DAO 的组合复用

类型 最大长度 备注 TINYTEXT 256 bytes TEXT 65,535 bytes ~64kb MEDIUMTEXT 16,777,215 bytes ~16MB LONGTEXT 4,294,967,295 bytes ~4GB

问题描述有这么一个需求，我需要将一个请求重写到另一个地址，然后再将这个地址代理到另一个服务。这个需求在实际开发中是很常见的，比如我们需要将一个旧的接口地址重写到新的接口地址，然后再将新的接口地址代理到后端服务。 如：请求 http://example.com/v1重写到 http://example.com/v2 然后再将 http://example.com/v2 代理到后端服务 http://127.0.0.1:8080/v2 解决方案在 Nginx 中，我们可以使用 rewrite 指令和 proxy_pass 指令来实现这个需求。 12345678server { listen 80; server_name example.com; location /v1/ { rewrite ^/v1/(.*) /v2/$1 break; proxy_pass http://127.0.0.1:8080 } 详细的参数说明： $1：匹配的第一个括号中的内容，即请求的路径。break：表示匹配成功一次后就停 ...

This worked for me: Open file /usr/local/bin/brew with vi (vi /usr/local/bin/brew)While on vi issue this commad (via esc or :) :set fileformat=unixClose file on vi via :wq!The brew command should be OK now. Regards.