问题描述

每次启动 PowerShell时都有明显的卡顿，启动时间长达数秒。经过排查，发现这是由于 Conda的初始化脚本导致的。

原因

在使用 conda init 命令配置 PowerShell 环境时，Conda会向配置文件（Profile）中注入一段初始化代码。这段代码会在每次启动PowerShell 时立即执行，加载整个 Conda 环境，从而拖慢启动速度。

排查过程

1. 测试当前启动时间 使用Measure-Command 测试加载配置文件的启动耗时：

   Measure-Command { pwsh.exe -Command "exit" }

   测试结果显示需要约 5 秒。

2. 测试裸启动时间测试不加载配置文件（-NoProfile）的启动耗时：

   Measure-Command { pwsh.exe -NoProfile -Command "exit" }

   结果仅需 0.5秒左右。巨大的时间差异证实了问题出在配置文件（Profile）的加载过程中。

3. 定位配置文件

   $PROFILE | Get-Member -Type NoteProperty

4. 分析配置文件内容 打开配置文件（通常是CurrentUserAllHosts），找到 Conda 注入的代码块：

   #region conda initialize# !! Contents within this block are managed by 'conda init' !!If (Test-Path "xx\Scripts\conda.exe") {    (& "xx\Scripts\conda.exe" "shell.powershell" "hook") | Out-String | ?{$_} | Invoke-Expression}#endregion

5. 验证假设临时注释掉上述代码块后，再次测试启动时间：

   Measure-Command { pwsh.exe -Command "exit" }Measure-Command { pwsh.exe -NoProfile -Command "exit" }

   发现与裸启动时间基本持平，确认该段代码是性能瓶颈的根源。

解决方案

直接注释掉代码虽然能解决启动慢的问题，但会导致无法使用conda 命令。更好的方案是将同步初始化改为懒加载（LazyLoading）：仅在首次输入 conda命令时才执行初始化逻辑。

注：只需将脚本中的 xx.exe 替换为你实际的 conda 安装路径即可。

#region conda initialize# ===== 配置：🛑 改为实际的 conda.exe 路径 =====$script:CondaExePath = 'xx\Scripts\conda.exe'# ===== 主逻辑 =====if (Test-Path -LiteralPath $script:CondaExePath -PathType Leaf) {        # 状态标记：防止递归调用    $script:CondaInitialized = $false        # 定义核心初始化逻辑    function Global:Invoke-CondaInit {        # 只有未初始化时才执行 hook 逻辑        if (-not $script:CondaInitialized) {            Write-Host "🔄 正在初始化 Conda..." -ForegroundColor Cyan            $script:CondaInitialized = $true                        try {                # 1. 获取 Hook 脚本 (屏蔽 stderr 警告)                $hookOutput = & $script:CondaExePath 'shell.powershell' 'hook' 2>$null                $exitCode = $LASTEXITCODE                                # 2. 严格检查：任何异常直接报错                if ($exitCode -ne 0) { throw "Conda hook 进程退出码异常: $exitCode" }                if ([string]::IsNullOrWhiteSpace($hookOutput)) { throw "Conda hook 返回空内容" }                                # 3. 执行官方 Hook                Invoke-Expression ($hookOutput | Out-String)                               # 4. 双重保险：确保 Global 作用域生效                try {                    $fn = Get-Command conda -CommandType Function -ErrorAction Stop                    Set-Item -Path Function:\Global:conda -Value $fn.ScriptBlock -Force                }                catch {                    throw "Hook 执行后未检测到 conda 函数，环境可能已损坏"                }                Write-Host "✓ Conda 初始化成功" -ForegroundColor Green            }            catch {                # 失败处理：重置状态并直接抛出致命错误                $script:CondaInitialized = $false                Write-Error "Conda 初始化失败: $($_.Exception.Message)" -ErrorAction Stop            }        }                # 执行用户命令        if ($args.Count -gt 0) {            & conda @args        }    }        # 应用代理：拦截首次调用    Set-Item Function:\Global:conda -Value { Invoke-CondaInit @args } -Force    }else {    # 路径配置错误的报错逻辑    Write-Warning "未找到 Conda: $script:CondaExePath"        function Global:conda {        Write-Error "Conda 配置路径无效: $script:CondaExePath" -ErrorAction Stop    }}#endregion

代码解释

当PowerShell启动时：

PowerShell 启动    ↓Set-Item Function:\Global:conda -Value { Invoke-CondaInit @args }    ↓此时 conda = Invoke-CondaInit

在上面的代码中，Set-Item Function:\Global:conda ... 会将conda 命令重定向到代理函数 Invoke-CondaInit。此时，当第一次调用 conda 命令时，会触发代理函数Invoke-CondaInit:

用户输入: conda -V    ↓调用代理函数 Invoke-CondaInit    ↓进入 Invoke-CondaInit    ↓执行官方 Hook: Invoke-Expression ($hookOutput | Out-String)    ↓【关键】官方 Hook 会定义一个新的 conda 函数！    ↓Set-Item -Path ... (仅作为防御性检查，通常官方 Hook 已经将 conda 函数作用到全局)    ↓此时 conda = 官方函数（覆盖了我们的代理）    ↓& conda @args  ← 调用的是官方函数    ↓用户再输入: conda activate xxx    ↓调用的是【官方 conda 函数】，不再是代理    ↓Invoke-CondaInit 永远不会再被调用

1. DNS：只负责“域名 → IP 的映射”

DNS（域名解析）只做一件事：

xx.example.com → 服务器公网 IP

它不涉及端口、不涉及防火墙、不涉及安全策略。你只是告诉全球的 DNS 服务器：

“访问这个域名，请去找这台服务器。”

2. 端口：服务监听的位置

服务器上的每一个服务，都需要监听一个端口，例如：

如果你的 xx 运行在：127.0.0.1:1234，那么它只允许本机访问。外网无论如何都无法访问这个端口，即使安全组放行了 1234 端口。

如果你的 xx 运行在：0.0.0.0:1234，那么它允许所有 IP 访问。但是，是否能从外网访问，还要看安全组中是否放行了 1234 端口。

3.安全组：决定外网能否访问某个端口

安全组是云厂商提供的入口防火墙，决定哪些端口可以从外网访问。例如：

只要你的安全组没有放行 1234，即便服务监听了0.0.0.0:1234，外网仍然无法访问。

4.反向代理（Nginx）：把外网请求转发给内部服务

反代负责将 80/443 的访问转发到内部端口，如：

https://xx.example.com       ↓Nginx（监听 80/443）       ↓127.0.0.1:1234（xx 后端）

反向代理的意义是：

• 外网用户只需要访问域名（80/443）
• 内部服务可以隐藏在任意端口
• 后端端口无需暴露给外网（更安全）

这就是为什么后端端口不用开放。

5. 常见问题

Q: 配置了反代后，我需要在云服务器后台开启 1234端口吗？

A: 完全不需要。 因为流量是先到达Nginx (443端口)，然后由 Nginx 在服务器内部通过localhost 转发给1234。外部防火墙根本看不到这个内部转发过程，所以 1234端口应当保持关闭状态。

Q:如何检测我的服务是否只监听在本地以及是否开启？

A: 使用 netstat 或ss 命令查看端口监听状态：

# 使用 netstatsudo netstat -ltn | grep 1234# 使用 sssudo ss -ltn | grep 1234# 正确的状态 (只允许本地)tcp  0  0  127.0.0.1:1234   0.0.0.0:* LISTEN# 危险的状态 (允许所有 IP)tcp  0  0  0.0.0.0:1234     0.0.0.0:* LISTEN

6. 总结

一张简单的关系图

┌──────────────────────────────┐│        用户访问域名           │└───────────────┬──────────────┘                ↓        DNS：解析域名 → 服务器 IP                ↓┌───────────────┴──────────────┐│     Nginx（监听 80 / 443）     ││  负责接收外网请求并做反向代理 │└───────────────┬──────────────┘                ↓     内部服务（如 127.0.0.1:1234）

如果你使用 Nginx 为 xx 或其他后端程序做反代：

• ✔ 必须开放的端口：80 / 443
• ❌ 不需要开放的端口：1234 等内部端口
• ✔ 内部服务保持监听 127.0.0.1 或 0.0.0.0 即可
• ✔ 只要做了反代，后端端口就不需要开放！

用一句话总结：

DNS负责找服务器，安全组控制外网访问权限，端口决定服务位置，反代负责把外部请求转发到内部服务。因此，反代后的后端端口无需对外开放。

Python的logging模块提供了灵活的日志记录功能，可用于调试和记录程序运行信息。

1 基本配置

将以下代码添加到Python文件中，以配置日志记录：

import loggingfrom pathlib import Path# 配置日志文件路径script_dir = Path(__file__).parent  # 获取当前脚本所在目录log_file_path = script_dir / 'log_file.log'  # 在脚本目录下创建日志文件# 配置日志logging.basicConfig(    level=logging.DEBUG,  # 设置日志级别    format='%(asctime)s - %(levelname)s - %(message)s',  # 设置日志格式    handlers=[        logging.StreamHandler(),  # 输出到控制台        logging.FileHandler(log_file_path, encoding='utf-8')  # 同时输出到文件    ])logger = logging.getLogger(__name__)  # 获取当前模块的logger# 使用示例：不同级别的日志记录logger.debug("这是调试信息")logger.info("这是一般信息") logger.warning("这是警告信息")logger.error("这是错误信息")logger.critical("这是严重错误信息")

2 高级配置

以下是一个更复杂的日志配置示例，作为模块使用。该示例展示了如何创建一个通用的日志配置类，支持多模块共享日志设置、按大小轮转、压缩旧日志、不同级别日志分文件、控制台输出和自定义过滤器。

import loggingimport osimport gzipfrom logging.handlers import RotatingFileHandlerfrom typing import Optional, Dict, Listimport shutilclass CompressedRotatingFileHandler(RotatingFileHandler):    """支持压缩的日志轮转处理器"""    def doRollover(self):        """重写doRollover方法来添加压缩功能"""        if self.stream:            self.stream.close()            self.stream = None        # 如果备份文件已存在，需要先轮转这些文件        if self.backupCount > 0:            # 删除最旧的一个文件(如果存在)            oldest_backup = f"{self.baseFilename}.{self.backupCount}.gz"            if os.path.exists(oldest_backup):                os.remove(oldest_backup)            # 轮转现有的备份文件            for i in range(self.backupCount - 1, 0, -1):                source = f"{self.baseFilename}.{i}.gz"                dest = f"{self.baseFilename}.{i + 1}.gz"                if os.path.exists(source):                    if os.path.exists(dest):                        os.remove(dest)                    os.rename(source, dest)            # 压缩当前日志为第一个备份            dest = f"{self.baseFilename}.1.gz"            if os.path.exists(self.baseFilename):                with open(self.baseFilename, 'rb') as f_in:                    with gzip.open(dest, 'wb') as f_out:                        shutil.copyfileobj(f_in, f_out)                os.remove(self.baseFilename)        # 创建新的空日志文件        self.mode = 'w'        self.stream = self._open()class KeywordFilter(logging.Filter):    def __init__(self, keyword: str):        super().__init__()        self.keyword = keyword    def filter(self, record: logging.LogRecord) -> bool:        # 仅当日志消息包含特定关键词时返回 True        return self.keyword in record.msgclass LoggerConfig:    """    通用日志配置类，支持多模块共享日志设置    特性：    1. 按大小轮转    2. 日志压缩    3. 不同级别日志分文件    4. 支持控制台输出    5. 支持自定义过滤器    """    _instance = None    _initialized = False    _loggers: Dict[str, logging.Logger] = {}    def __new__(cls, *args, **kwargs):        if cls._instance is None:            cls._instance = super(LoggerConfig, cls).__new__(cls)        return cls._instance    def __init__(self,                 log_dir: str = './logs',                 log_level: int = logging.INFO,                 max_bytes: int = 5 * 1024 * 1024,  # 默认5MB                 backup_count: int = 20,                 enable_console: bool = True,                 compress_logs: bool = True,                 custom_filters: List[Dict] = None,                 extra_handlers: List[logging.Handler] = None):        """        初始化日志配置        Args:            log_dir: 日志目录            log_level: 基础日志级别            max_bytes: 单个日志文件最大字节数            backup_count: 保留的备份文件数量            enable_console: 是否启用控制台输出            compress_logs: 是否压缩旧日志            custom_filters: 自定义过滤器列表            extra_handlers: 额外的处理器列表        """        # 单例模式：确保只初始化一次        if self._initialized:            return        self.log_dir = log_dir        self.log_level = log_level        self.max_bytes = max_bytes        self.backup_count = backup_count        self.enable_console = enable_console        self.compress_logs = compress_logs        self.custom_filters = custom_filters or []        self.extra_handlers = extra_handlers or []        # 创建日志目录        os.makedirs(log_dir, exist_ok=True)        # 默认格式化器        self.default_formatter = logging.Formatter(            '%(asctime)s - %(name)s - %(levelname)s - %(message)s'        )        self._initialized = True    def get_logger(self, name: str, formatter: Optional[logging.Formatter] = None) -> logging.Logger:        """        获取或创建logger        Args:            name: logger名称            formatter: 自定义格式化器        Returns:            logging.Logger: 配置好的logger        """        # 如果已存在该logger，直接返回        if name in self._loggers:            return self._loggers[name]        # 创建logger        logger = logging.getLogger(name)        # 清理可能存在的handlers        if logger.hasHandlers():            logger.handlers.clear()        # 设置日志级别        logger.setLevel(self.log_level)        formatter = formatter or self.default_formatter        # 添加控制台处理器        if self.enable_console:            console_handler = logging.StreamHandler()            console_handler.setFormatter(formatter)            logger.addHandler(console_handler)        # 为不同级别创建单独的日志文件        log_levels = [            (logging.DEBUG, 'debug'),            (logging.INFO, 'info'),            (logging.WARNING, 'warning'),            (logging.ERROR, 'error'),            (logging.CRITICAL, 'critical')        ]        for level, level_name in log_levels:            if level >= self.log_level:                handler = self._create_rotating_handler(                    os.path.join(self.log_dir, f"LOG_{level_name}.log"),                    formatter,                    level                )                logger.addHandler(handler)        # 添加额外的处理器        if self.extra_handlers:            for handler in self.extra_handlers:                handler.setFormatter(formatter)                logger.addHandler(handler)        # 添加自定义过滤器        if self.custom_filters:            for filter_config in self.custom_filters:                filter_class = filter_config.get('filter_class')                args = filter_config.get('args', {})                if filter_class:                    filter_instance = filter_class(**args)                    logger.addFilter(filter_instance)        # 禁止向父logger传递日志        logger.propagate = False        # 缓存logger实例        self._loggers[name] = logger        return logger    def _create_rotating_handler(self,                                 filename: str,                                 formatter: logging.Formatter,                                 level: int) -> RotatingFileHandler:        """        创建轮转处理器        Args:            filename: 日志文件名            formatter: 格式化器            level: 日志级别        Returns:            RotatingFileHandler: 配置好的处理器        """        handler_class = CompressedRotatingFileHandler if self.compress_logs else RotatingFileHandler        handler = handler_class(            filename,            maxBytes=self.max_bytes,            backupCount=self.backup_count,            encoding='utf-8'        )        handler.setLevel(level)        handler.setFormatter(formatter)        return handlerdef setLogConfig(module_name=None,                 log_dir='./logs',                 log_level=logging.DEBUG,                 max_bytes=5 * 1024 * 1024,  # 5MB                 backup_count=20,                 enable_console=True,                 compress_logs=True,                 custom_filters=None,                 extra_handlers=None):    """    快速设置并获取logger的便捷函数    Args:        module_name: 模块名称，用于标识日志来源        log_dir: 日志保存目录        log_level: 日志级别        max_bytes: 单个日志文件最大字节数        backup_count: 保留的备份文件数量        enable_console: 是否启用控制台输出        compress_logs: 是否压缩旧日志        custom_filters: 自定义过滤器列表，例如custom_filters=[{'filter_class': KeywordFilter, 'args': {'keyword': 'critical'}}]        extra_handlers: 额外的处理器列表    Returns:        logging.Logger: 配置好的logger实例    """    # 初始化日志配置    log_config = LoggerConfig(        log_dir=log_dir,        log_level=log_level,        max_bytes=max_bytes,        backup_count=backup_count,        enable_console=enable_console,        compress_logs=compress_logs,        custom_filters=custom_filters,        extra_handlers=extra_handlers    )    # 自动获取调用者的模块名称    if module_name is None:        import inspect        caller_frame = inspect.stack()[1]        module_name = caller_frame.frame.f_globals['__name__']        # 如果没有提供module_name，则通过调用栈获取调用者的__name__    return log_config.get_logger(name=module_name, formatter=None)# 使用示例if __name__ == '__main__':    logger = setLogConfig('test_module')    # 使用logger    logger.debug('这是一条调试日志')    logger.info('这是一条信息日志')    logger.warning('这是一条警告日志')    logger.error('这是一条错误日志')    logger.critical('这是一条严重错误日志')

资源托管方案

在搭建博客时，通常会涉及到一些静态资源的托管问题，比如图片、视频、音频等。这里列出几种常见的资源托管方案，供参考：

优缺点分析

1 本地

• 优点：
  • 方便，直接放在博客的source文件夹下，使用相对路径引用即可。
  • 不需要额外的配置和管理。
  • 跟随博客同步到github仓库，方便备份和版本控制。
• 缺点：
  • 资源文件较大时，可能会导致博客仓库过大，影响克隆和下载速度。
  • 仓库容量有限，超过限制后也难以清理。

2 github repo

一般配合jsDelivr使用，cdn加速。

• 优点：
  • 可以将assets资源放在单独的github仓库管理，避免影响博客仓库的大小。
  • 可以使用github的版本控制和备份功能，方便管理和维护。
• 缺点：
  • 需要额外的配置和管理，增加了复杂性。
  • 并不推荐github做资源托管，限制大文件和高流量访问，尤其是直接调用raw.githubusercontent.com的资源。

3 云服务器

• 优点：
  • 可以将assets放在云服务器静态网页上，方便管理和维护。
  • 资源完全自由掌控，可以设置访问权限和流量限制，隐私性最好。
  • 容量和带宽取决于云服务器的配置。
• 缺点：
  • 需要额外的配置和管理，增加了复杂性。
  • 需要支付云服务器的费用，增加了成本。

4 npm

• 优点：
  • 可以将assets发布到npm，经过 unpkg/jsDelivr CDN使用，方便快捷。
  • 可以使用npm的版本控制和备份功能，方便管理和维护。
• 缺点：
  • 需要额外的配置和管理，增加了复杂性。
  • 资源更新后需要重新发布到npm
  • 包的容量有限制

总结

将资源分开管理

1. 将配置文件放在source文件夹下，使用相对路径引用。
2. 将不常变动的资源打包为assets，依据喜好放于云服务器或者npm(使用jsDelivr/unpkgCDN)。
3. 经常变动的资源如果较大，放在云服务器或者githubrepo(使用jsDelivr)上，如果较小，放在source文件夹下。
4. 十分推荐为博客(和云服务器，如果使用的话)添加CloudflareCDN加速，免费版足够使用。

CDN，全称 Content DeliveryNetwork（内容分发网络），是一种通过分布式部署的服务器网络来加速和优化内容传输的技术。它的核心目标是让用户能够就近获取所需的网页、视频、图片、脚本等内容，从而提升访问速度和体验，同时减轻源站服务器的压力。

1 原理

1. 内容缓存与分发 (Caching & Distribution):这是CDN最基础也是最关键的技术。CDN会将网站的静态内容（如图片、视频、CSS/JS文件等）主动或被动地从源站服务器缓存到遍布全球的边缘节点服务器上。当用户发起访问请求时，请求会被引导至离用户地理位置最近、网络延迟最低的边缘节点，该节点会直接将缓存的内容响应给用户，避免了对源站的直接访问，极大地缩短了物理距离和数据传输时间。
2. 负载均衡与智能调度 (Load Balancing & Intelligent Scheduling):CDN拥有一个智能的“大脑”——全局负载均衡（GSLB）系统。这个系统会实时监控所有边缘节点的健康状况、负载情况以及到用户的网络链路质量。当用户发起请求时，GSLB会综合分析用户的IP地址、地理位置、运营商网络等信息，通过DNS解析或HTTP重定向等技术，将用户的请求“调度”到最优的边缘节点上，确保用户获得最快、最稳定的访问体验。

2 工作流程

用户使用CDN服务访问一个网站的完整流程，可以分解为以下几个关键步骤：

前提：网站主已经将其域名接入CDN服务，并在DNS服务商处将域名解析指向CDN服务商提供的CNAME记录。

1. 用户发起请求： 当用户在浏览器中输入网址（例如www.example.com）后，计算机会向本地DNS服务器（LocalDNS）发起域名解析请求。
2. CNAME解析至CDN的DNS调度系统： LocalDNS从域名的权威DNS服务器获取到该域名被配置了一条CNAME记录，指向了CDN服务商的域名（例如www.example.com.cdn.cloudflare.net）。于是，LocalDNS会再次向CDN的DNS调度系统发起请求。
3. 智能调度，返回最优节点IP：CDN的DNS调度系统（即GSLB）接收到请求后，会根据一系列策略进行智能决策：
   • 地理位置判断：分析用户的IP地址，判断其所在的地理位置和运营商网络。
   • 节点健康度检测：排除掉故障或负载过高的边缘节点。
   • 网络质量探测：评估各个节点到用户的网络延迟和丢包率。
   • 综合以上信息，选择出一个对该用户来说“最优”的边缘节点，并将其IP地址返回给LocalDNS。
4. 获取最优节点IP： LocalDNS将获取到的最优边缘节点的IP地址返回给用户的计算机。
5. 用户与边缘节点建立连接：用户的浏览器向这个最优的边缘节点IP地址发起HTTP/HTTPS请求，请求获取具体的网页内容（如一张图片）。
6. 边缘节点响应：
   • 缓存命中（Cache Hit）：如果该边缘节点已经缓存了用户请求的内容，并且缓存尚未过期，它会直接将内容发送给用户。这是最理想、最快速的情况。
   • 缓存未命中（Cache Miss）：如果该节点没有缓存该内容，或者缓存已经过期，它会代表用户向源站服务器发起请求，获取最新的内容。
7. 回源与缓存：边缘节点从源站获取到内容后，一方面将其发送给用户，另一方面会按照预设的缓存策略（如缓存时间、缓存规则等）将内容存储在本地，以便后续有相同请求时可以直接响应。

通过这样一套完整、自动化的流程，CDN成功地将用户访问流量分散到了各个边缘节点，既减轻了源站服务器的压力，又显著提升了终端用户的访问速度和体验。

3 优势

凭借其独特的技术原理，CDN被广泛应用于各种互联网业务场景，其主要优势包括：

• 加速网站访问：显著减少网页加载时间，提升用户体验，降低用户流失率。
• 分担源站压力：大部分用户请求由CDN边缘节点处理，大幅降低源站服务器的负载和带宽消耗成本。
• 提升可用性与可靠性：单个或多个节点的故障不会影响整个服务的可用性，CDN的分布式架构提供了天然的冗余。
• 增强安全性：CDN可以隐藏源站IP，并提供DDoS攻击防护、WAF（Web应用防火墙）等安全功能，保护源站免受网络攻击。
• 支持大规模分发：尤其适用于视频点播、直播、大文件下载、游戏加速等需要处理海量并发请求和高带宽流量的场景。

CDN已经成为现代互联网不可或缺的基础设施，它通过智能的调度和分布式的缓存，有效地解决了因地理距离和网络拥塞带来的访问延迟问题，为全球用户提供了更快速、更可靠、更安全的网络访问体验。

4 使用

常见的 CDN 服务有 cdnjs、unpkg 和jsDelivr，它们各自有不同的特点和功能。

1. unpkg类型：只支持 npm 包，npm 包加速
   • 提供方
     • unpkg官方: https://unpkg.com
   • 示例:{url}/@{organization}/{package-name}@{version}/path/to/file
2. jsdelivr类型：支持 npm 包 和 GitHub 仓库，npm 包 和 GitHub 仓库加速
   • 提供方
     • jsdelivr官方: https://cdn.jsdelivr.net
     • fastly: https://fastly.jsdelivr.net
     • cloudflare: https://testingcf.jsdelivr.net
     • gcore: gcore.jsdelivr.net
   • npm:{url}/npm/@{organization}/{package-name}@{version}/path/to/file
   • GitHub:{url}/gh/{organization}/{repository}@{version}/path/to/file
3. cdnjs类型：只支持已加入的开源库，JavaScript/CSS 库加速
   • 基础URL: https://cdnjs.cloudflare.com/ajax/libs/
   • 示例:https://cdnjs.cloudflare.com/ajax/libs/jquery/3.6.0/jquery.min.js

.gitignore 文件用于指定哪些文件或目录在 Git版本控制中被忽略。它可以避免将不必要的文件（如编译产物、临时文件等）提交到版本库中。

# 忽略特定文件secret.txt# 忽略特定目录temp/# 忽略特定目录下的所有文件(但保留temp目录本身)# 如果 temp/ 目录是空的，Git 默认不会追踪空目录，通常要用 .gitkeep 之类的文件强制保留temp/*# 忽略特定目录下的所有 .tmp 文件temp/*.tmp# 忽略特定目录下的所有文件和子目录，但保留某个文件temp/*!temp/keep.txt# 忽略特定目录下的所有文件和子目录，但保留某个目录temp/*!temp/keep/

2. 清除已跟踪的文件

不会删除 Git 提交历史中的文件，它 只删除工作区（workingdirectory）和未跟踪的文件，不会影响 Git 版本库的提交记录:

git clean -n -d -x  # 预览即将删除的文件git clean -f -d -x  # 确认无误后执行删除

3. 回退以前的提交

3.1 reset 硬回退

git reset --hard commit id

此时再推到远程仓库用 git push 会报错，需要用git push -f 强推上去

3.2 revert 软回退

git revert -n commit id

此时会在当前分支上生成一个新的提交，内容是将指定的提交回退到当前分支的状态。注意：-n选项表示不会立即创建一个新的提交，而是将变更放入暂存区

4. 提交规范

4.1 提交信息的基本结构

一个标准的 Git 提交信息通常包括三部分：

<类型>(<范围>): <简短描述><详细描述><页脚注释>

• 类型 (Type)：描述提交的类别，指明提交的性质。
• 范围 (Scope)：指定变更的具体模块、功能或文件。
• 简短描述：对本次提交的简要总结。
• 详细描述（可选）：提供更详细的信息，解释为什么要做这个提交、如何做的、解决了什么问题等。
• 页脚注释（可选）：链接到项目管理工具中的任务、bug或故事等。

4.2 常见的提交类型

这些类型通常是采用 ConventionalCommits 标准的常见值，目的是使提交信息一致且具有结构化。

1. fix: 类型 为 fix 的提交表示在代码库中修复了一个bug。
2. feat: 类型 为 feat的提交表示在代码库中新增了一个功能。
3. BREAKING CHANGE: 在脚注中包含 BREAKING CHANGE: 或<类型>(范围) 后面有一个 ! 的提交，表示引入了破坏性 API 变更。破坏性变更可以是任意类型提交的一部分。
4. build:用于修改项目构建系统，例如修改依赖库、外部接口或者升级 Node版本等；
5. chore:用于对非业务性代码进行修改，例如修改构建流程或者工具配置等；
6. ci: 用于修改持续集成流程，例如修改 Travis、Jenkins等工作流配置；
7. docs: 用于修改文档，例如修改 README 文件、API文档等；
8. style:用于修改代码的样式，例如调整缩进、空格、空行等；
9. refactor:用于重构代码，例如修改代码结构、变量名、函数名等但不修改功能逻辑；
10. perf:用于优化性能，例如提升代码的性能、减少内存占用等；
11. test:用于修改测试用例，例如添加、删除、修改代码的测试用例等。

每次提交应该只包含一个逻辑变更，避免混合多个不相关的修改。

5. git全局配置推荐

[user]    name = xx    email = xx@xx.com[http "https://github.com"]    proxy = 127.0.0.1:7890       # GitHub 代理，可根据实际网络环境修改[core]    autocrlf = true              # 自动转换换行符，Windows 推荐 true，macOS/Linux 推荐 input    quotepath = false            # 中文路径不再转义显示为 \uXXXX    editor = code --wait         # 默认编辑器 VSCode，可改为 notepad 或 vim    preloadindex = true          # 加快 git status 速度    fscache = true               # Windows 下缓存文件系统信息，提高性能    untrackedCache = true        # 加速未跟踪文件检测，特别是大仓库[color]    ui = auto                    # Git 命令输出自动彩色显示（log、diff 等）[alias]    st = status                  # git st → git status    co = checkout                # git co → git checkout    br = branch                  # git br → git branch    ci = commit                  # git ci → git commit    df = diff                     # git df → git diff    lg = log --graph --decorate --pretty=format:'%C(yellow)%h%Creset -%C(cyan)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative                                  # 美观的提交历史，带分支、标签、图形化显示    last = log -1 HEAD           # 查看最后一次提交    unstage = reset HEAD --      # 取消暂存区文件    amend = commit --amend --no-edit  # 修改最后一次提交但不更改提交信息[diff]    tool = vscode    algorithm = histogram        # 更智能的 diff 算法，处理大文件和移动代码块更准确    colorMoved = plain           # 启用移动代码块检测，显示更直观    mnemonicPrefix = true        # diff 前缀更易理解    renames = true               # 自动检测文件重命名    indentHeuristic = true       # 更智能的 diff 块划分    compactionHeuristic = true   # 优化 diff 输出可读性[difftool "vscode"]    cmd = code --wait --diff $LOCAL $REMOTE  # 使用 VSCode 作为 diff 工具[merge]    tool = vscode[mergetool "vscode"]    cmd = code --wait $MERGED                 # 使用 VSCode 作为 merge 工具[pull]    rebase = false              # 避免默认 rebase，可根据个人习惯改 true[push]    default = simple            # 避免推送到错误分支    autoSetupRemote = true      # 新建分支时自动设置上游分支    followTags = true           # 推送 commit 时自动推送关联的 tag[init]    defaultBranch = master      # 初始化仓库默认分支名，可改为 main[column]    ui = auto                   # 列表命令自动对齐输出[branch]    sort = -committerdate       # 分支列表按最近提交时间排序[tag]    sort = version:refname      # 标签列表按版本号排序[fetch]    prune = true                # 自动删除远程已删除的分支    pruneTags = true            # 自动删除远程已删除的标签    # fetch.all 可选，根据项目是否多远程决定是否开启    # git config --global fetch.all true[help]    autocorrect = prompt        # 输入命令有误时提示纠正，避免误操作[commit]    verbose = true              # 提交时显示 diff 内容，方便检查[rerere]    enabled = true              # 启用冲突重用功能    autoupdate = true           # 自动应用已解决的冲突[rebase]    autoStash = true            # rebase 前自动 stash，完成后自动 pop    autoSquash = true           # 自动处理 fixup!/squash! 提交    missingCommitsCheck = warn  # 丢失提交时警告[stash]    showPatch = true            # stash show 默认显示 diff[status]    submoduleSummary = true     # 显示子模块变更摘要    showStash = true            # 显示 stash 数量    aheadBehind = true          # 显示分支领先/落后信息[index]    threads = true              # 多线程加速索引操作

在网页中添加 Live2D 看板娘。兼容 PJAX，支持无刷新加载。(注：已不再需要配置依赖 jQuery 和 Font Awesome)

代码： live2d-widgetlive2d_api

博文：
网页添加 Live2D看板娘 Live2D 看板娘API 迁移公告

1 简单配置

只需要最基础的功能，那么只用将这一行代码加入 html 页面的head 或 body 中，即可加载看板娘：

<script src="https://fastly.jsdelivr.net/gh/stevenjoezhang/live2d-widget@latest/autoload.js"></script>

1. 添加代码的位置取决于你的网站的构建方式。例如，如果你使用的是 Hexo，那么需要在主题的模版文件中添加以上代码。对于用各种模版引擎生成的页面，修改方法类似。
   
2. 如果网站启用了 PJAX，由于看板娘不必每页刷新，需要注意将该脚本放到PJAX 刷新区域之外。

2 进阶配置

2.1 修改autoload.js文件

下载live2d-widget源码，找到其中的autoload.js文件，修改其中的配置项。

autoload.js会自动加载三个文件：waifu.css，live2d.min.js和 waifu-tips.js。waifu-tips.js 会创建initWidget函数，这就是加载看板娘的主函数。initWidget 函数接收一个Object 类型的参数，作为看板娘的配置。以下是配置选项：

1️⃣ live2d_path 是 live2d-widget的资源路径，可以自行修改。

下载live2d-widget

1. 本地存放：将下载的仓库放在本地目录下，指向本地路径，例如/assets/live2d-widget/。如hexo，放在博客源文件目录下（source 目录），需要设置 skip_render。
2. 云端存放：将下载的仓库上传到云端，指向云端路径
   • github：使用 jsdelivr，例如https://cdn.jsdelivr.net/gh/username/live2d-widget@latest/，需要创建新的git tag 并推送至 GitHub 仓库中，否则此处的 @latest仍然指向更新前的文件。
   • npm：使用 unpkg或者jsdelivr，例如https://unpkg.com/[package_name]/@latest/ 或https://cdn.jsdelivr.net/npm/[package_name]/@latest/
   • 云服务器: 新建静态项目，例如https://example.com/path/to/live2d-widget/

2️⃣ apiPath 和 cdnPath两个参数设置其中一项即可。

下载live2d_api

• apiPath 是后端 API 的 URL，可以自行搭建，并增加模型。
  • 需要支持 GET 请求，因此需要建站，以宝塔面板为例：
    • 首先，在宝塔面板创建新站点，设置好 PHP 版本（不是纯静态），并添加上SSL 证书。
    • 然后，删去网站根目录 /www/wwwroot/api/下默认添加创建的所有文件。
    • 打开 SSH 终端，把 Live2D API 源代码放到网站 live2d/ 目录
• cdnPath 则是类似于 live2d_path的路径，用于加载模型文件。
  • 本地存放和云端存放同上。

2.2 添加autoload.js文件

修改live2d_path后将这一行代码加入 html 页面的head 或 body 中，即可加载看板娘：

<script src="{live2d_path}/autoload.js"></script>

2.3 测试

不妨试试能否正常地通过浏览器打开 autoload.js 和live2d.min.js等文件，并确认这些文件的内容是完整和正确的。

3 高级配置

修改样式和模型：自行查阅两个仓库的README.md文件和源码。

目前很多面板支持一键配置，以下是私有部署方式介绍

云端部署

1. 在 TwiKoo 官网找到云函数部署的私有部署方式，按照文档进行配置。
2. 下载nodejs选择最新的LTS版本，Linux，nvm，npm。按照命令安装。
3. 指定镜像源：npm config set registry https://registry.npmmirror.com
4. 安装 Twikoo server:npm i -g tkserver查看是否安装成功：npm ls tkserver -g
5. 配置环境变量，主要关注以下几个参数：
   • TWIKOO_DATA：lokijs 数据库存储路径，默认是./data。
   • TWIKOO_PORT：服务端口，默认是 8080
   • TWIKOO_IP_HEADERS：在特殊情况下使用，如使用了CloudFlare CDN 它会将请求 IP 写到请求头的 cf-connecting-ip字段上，为了能够正确的获取请求 IP 你可以写成[“headers.cf-connecting-ip”]，默认是 []
6. 启动服务
   • 创建一个文件夹，如/www/wwwroot/twikoo，在该文件夹下执行启动命令即可将数据库文件存储在该文件夹下
   • export TWIKOO_DATA=/www/wwwroot/twikoo/data
   • export TWIKOO_PORT=xxxx
   • export TWIKOO_IP_HEADERS=["headers.cf-connecting-ip"]
   • source ~/.bashrc
   • 检查环境变量是否设置成功(注意：有时设置不成功，可以直接添加到/root/.bashrc中)：
     • export | grep TWIKOO
     • 粗略启动服务tkserver并访问http://ip:xxxx查看是否成功（注1）
7. 在新文件夹下nohup tkserver >> tkserver.log 2>&1 &命令后台启动，访问http://服务端IP:端口号测试服务是否启动成功。但是概率存在使用nohup &命令运行shell脚本，关闭终端仍然退出(可以试试exit命令注销终端)……
8. 配置代理实现 HTTPS 访问:
   • 添加纯静态站点：PHP项目，twikoo.{域名}
   • 配置ssl证书:let’s encrypt 手动解析 通配符修改对应的阿里云和cloudflare的DNS解析，也可能只需要修改cloudflare的DNS解析
   • 添加反向代理: 代理名称：twikoo，目标URL：http://127.0.0.1:{端口}，代理域名：$host
9. 最终访问地址为：https://twikoo.{域名}
10. 注意定期备份数据库文件，防止数据丢失

前端配置

到博客配置文件中配置 envId 为 https:// 加域名（例如 https://twikoo.yourdomain.com）

更新云端

1. 停止旧版本kill $(ps -ef | grep tkserver | grep -v 'grep' | awk '{print $2}')
2. 拉取新版本 npm i -g tkserver@latest
3. 回到上文第7步重新启动服务

注1：前提是需要在服务器安全组和宝塔面板中开放该端口，用完关闭这两个端口。或者先配置反向代理，直接访问域名。就不需要开放端口了。

强化学习解决决策问题的思路可以分为两大类：一类是”评估价值后决策”，另一类是”直接优化决策”。这就是我们常说的基于值函数的方法和基于策略的方法。

1.1基于值函数的方法：先评估，再决策

想象你是一个下棋的新手，如何提高棋艺？一个直观的想法是：学会评估每个局面的好坏，然后选择能达到最好局面的走法。这就是基于值函数方法的核心思想。

核心理念

基于值函数的方法通过学习价值评估函数来指导决策：

• 值函数评估：基于值函数的方法主要通过估计状态值函数( V(s) ) 或动作价值函数 ( Q(s, a) )来评估每个状态或状态-动作对的优劣。这里，( V(s) ) 表示在状态 ( s )下能获得的期望累计奖励，而 ( Q(s, a) ) 则表示在状态 ( s ) 采取动作 ( a )后的期望累计奖励。
• 策略间接导出：这些方法通常不直接表示策略，而是通过优化值函数，然后从中推导出最优策略。例如，在给定( Q(s, a) ) 的情况下，可以通过选择使 ( Q(s, a) )最大的动作来获得最优策略。
• 状态价值函数 \(V(s)\)：评估”在状态s下，按照当前策略能获得多少长期奖励”
• 动作价值函数 \(Q(s,a)\)：评估”在状态s下采取动作a，能获得多少长期奖励”

有了这些价值评估，策略就水到渠成了——总是选择价值最高的动作。

典型算法

Q学习(Q-Learning)：最经典的值函数方法

• 直接学习最优动作价值函数 \(Q^*(s,a)\)
• 采用”时间差分”的思想逐步改进Q值估计
• 属于off-policy算法，可以从任意行为策略中学习

深度Q网络(DQN)：Q学习的深度学习版本

• 用神经网络近似Q函数，处理高维状态空间
• 引入经验回放和目标网络等技巧提高稳定性

1.2基于策略的方法：直接优化决策

如果说值函数方法是”三思而后行”，那么策略方法就是”熟能生巧”——直接练习决策过程本身，通过不断试错来改进策略。

核心理念

基于策略的方法将策略参数化为 \(\pi_\theta(a|s)\)，直接优化策略参数 \(\theta\)：

• 目标明确：最大化期望累积奖励 \(J(\theta) = \mathbb{E}_{\tau \sim\pi_\theta}[R(\tau)]\)
• 梯度上升：利用策略梯度定理计算参数更新方向
• 自然探索：随机策略天然具备探索能力

策略梯度定理

策略优化的数学基础来自于著名的策略梯度定理：

\[\nabla_\theta J(\theta) =\mathbb{E}_{\pi_\theta}[\nabla_\theta \log \pi_\theta(a|s) \cdotQ^{\pi_\theta}(s,a)]\]

这个公式告诉我们：如果某个动作的价值高，就增加选择它的概率；反之则降低概率。

典型算法

REINFORCE算法：最基础的策略梯度方法

• 使用蒙特卡洛方法估计回报
• 简单直接，但方差较大

PPO(Proximal PolicyOptimization)：现代策略优化的代表

• 通过”信任区域”思想控制策略更新幅度
• 在样本效率和稳定性间取得良好平衡

1.3 两种方法的深度对比

值函数方法的特点

• 样本效率高，能从有限经验中高效学习
• 理论基础扎实，基于贝尔曼方程
• 在离散动作空间中表现优异
• 难以处理连续或高维动作空间
• 需要额外机制平衡探索与利用
• 函数近似可能导致不稳定

策略方法的特点

• 自然处理连续动作空间
• 策略表达能力强，可学习复杂行为
• 收敛性保证较好（在合适条件下）
• 样本需求量大
• 梯度估计方差高，需要降方差技巧
• 容易陷入局部最优

1.4 融合之道：Actor-Critic方法

既然两种方法各有所长，自然有人想到将它们结合起来。这就是Actor-Critic方法的核心思想：

• Actor(演员)：基于策略的组件，负责选择动作
• Critic(评论家)：基于值函数的组件，负责评估动作价值

这种结合带来了显著优势：

1. Critic帮助Actor减少梯度方差
2. Actor为Critic提供更好的探索策略
3. 两者相互促进，加速收敛

2.动态规划中的经典对决：策略迭代 vs 价值迭代

在基于值函数的方法中，动态规划提供了两种经典的求解思路。需要注意的是，策略迭代和价值迭代都属于基于值函数的方法，它们的区别在于如何利用值函数来优化策略。

2.1 策略迭代

策略迭代是一种通过不断交替执行策略评估和策略改进来找到最优策略的方法。

• 策略评估：固定当前策略，计算该策略下所有状态的值函数(V^(s))，即评估在当前策略下，每个状态的长期奖励。
• 策略改进：利用评估出的值函数，改进当前策略，即在每个状态下选择使值函数最大的动作。

策略迭代的步骤是：

1. 初始化策略 (_0)。
2. 对策略 (_i) 进行策略评估，计算对应的值函数 (V^{_i}(s))。
3. 基于 (V^{i}(s)) 改进策略，得到新的策略 ({i+1})。
4. 重复步骤 2 和 3，直到策略收敛到最优策略 (^*)。

2.2 价值迭代

价值迭代通过直接更新值函数的方式来迭代逼近最优值函数(V^*(s))，然后通过值函数导出策略。

• 每一步都会对每个状态 (s) 更新其值函数为最大化预期奖励的值
• 通过不断更新值函数，逐步逼近最优值函数。当值函数收敛时，可以通过选择最大化值函数的动作来获得最优策略。

价值迭代的步骤是：

1. 初始化值函数 (V_0(s))。
2. 对每个状态 (s)，更新值函数 (V_{i+1}(s))，使其最大化预期回报。
3. 重复上述过程，直到值函数收敛。
4. 当值函数收敛后，通过选择使 (V(s)) 最大的动作(a)，导出最优策略。

2.3 策略迭代 vs 价值迭代

• 策略迭代：交替执行完整的策略评估和策略改进，计算较精确的策略更新，通常收敛较快，但每次评估需要花费较多时间。
• 价值迭代：在更新值函数的同时隐式优化策略，每次更新的粒度较小，虽然更新速度快，但可能需要更多迭代次数才能达到收敛。

深度确定性策略梯度是在动作空间无限的环境使用off-policy的actor-critic算法。它它的actor是一个确定性策略，通过梯度上升法来最大化Q值；它的critic是一个Q网络，通过梯度下降法来最小化Q值的TD误差。

12.1 DDPG算法

12.1.1 算法引出

1. TRPO和PPO是on-policy的actor-critic算法，这意味着它们只能在当前策略上进行更新，样本效率较低。
2. DQN是off-policy的Q-learning算法，直接估计Q值，样本效率较高，但是但是它只能处理动作空间有限的环境，这是因为它需要从所有动作中挑选一个\(Q\)值最大的动作。虽然可以将将动作空间离散化，但这比较粗糙，无法精细控制。
3. TRPO和PPO学习的是随机策略，而DDPG学习的确定性策略。随机策略可以表示为\(a\sim\pi_\theta(a|s)\)，确定性策略可以表示为\(a=\mu_\theta(s)\)。

12.1.2 算法公式

确定性策略梯度定理：

\[\nabla_\theta J(\mu_\theta)=\mathbb{E}_{s\sim \rho_\mu,a\sim\mu_\theta}[\nabla_\theta \mu_\theta(s)\nabla_aQ_\phi(s,a)|_{a=\mu_\theta(s)}]\]

这个公式可以理解为：假定现在已有函数\(Q\)，给定一个状态\(s\)，但由于现在动作空间是无限的，所以无法遍历所有动作来得到最大的\(Q\)值，因此我们用策略\(\mu_\theta(s)\)来找到一个动作\(a\)，使得\(Q(s,a)\)最大。此时，\(Q\)就是critic,\(\mu_\theta(s)\)就是actor。

12.1.3 算法描述

DDPG要用到4个网络：\(\mu,\mu',Q,Q'\)。其中\(\mu\)是actor，\(Q\)是critic，\(\mu'\)是actor的target网络，\(Q'\)是critic的target网络。

目标网络的的更新方式是软更新： \[\omega^-=\tau\omega+(1-\tau)\omega^-\] 其中\(\tau\)是更新系数，通常很小的一个数。当\(\tau = 1\)时，就和DQN更新方式一样了。

另外，由于函数\(Q\)存在\(Q\)值估值过高的问题，DDPG 采用了 Double DQN中的技术来更新\(Q\)网络。 但是，由于DDPG采用的是确定性策略，它本身的探索仍然十分有限。作为一种离线策略的算法，DDPG在行为策略上引入一个随机噪声\(\mathcal{N}\)来进行探索。

12.1.4 算法流程

1. 随机初始化actor和critic的网络参数\(\theta\)和\(\omega\)，初始化噪声过程\(\mathcal{N}\)。
2. 复制\(\theta\)和\(\omega\)到\(\theta^-\)和\(\omega^-\)，初始化目标网络。
3. 初始化经验回放池\(\mathcal{D}\)。
4. for 轮次\(episode=1,2,...,E\) do
   • 初始化随机过程\(\mathcal{N}\)用来探索。
   • 获取环境初始状态\(s_1\)。
   • for 时间步 t=1,2,…,T do
     • 根据当前策略和噪声选择动作\(a_t =\mu_\theta(s_t)+\mathcal{N}\)。
     • 执行动作\(a_t\)，得到新状态\(s_{t+1}\)，奖励\(r_t\)。
     • 将\((s_t,a_t,r_t,s_{t+1})\)存入\(\mathcal{D}\)。
     • 从\(\mathcal{D}\)中随机采样\(N\)个样本\({(s_i,a_i,r_i,s_{i+1})}_{i=1,2,...,N}\)。
     • 对每个样本\(i\)，用目标网络计算\(y_i=r_i+\gammaQ_\phi(s_{i+1},\mu_\theta(s_{i+1}))\)。
     • 最小化目标损失函数\(L(\omega)=\frac{1}{N}\sum_i(y_i-Q_\omega(s_i,a_i))^2\)，更新当前critic网络参数\(\omega\)。
     • 计算采样的\(N\)个动作的策略梯度，更新当前actor网络参数\(\theta\)。\(\nabla_\theta J \approx\frac{1}{N}\sum_i\nabla_\theta \mu_\theta(s_i)\nabla_aQ_\phi(s_i,a_i)|_{a=\mu_\theta(s_i)}\)
     • 更新目标网络。\(\omega^-=\tau\omega+(1-\tau)\omega^-,\theta^-=\tau\theta+(1-\tau)\theta^-\)。
   • end for
5. end for