前言

这是一个关于调试的真实故事。一个看似简单的图片服务404问题，最终花费了3天时间才找到根本原因。问题的表象很简单，但背后涉及到Django图片处理、nginx内部重定向、文件系统符号链接以及nginx location优先级等多个技术点的交互。

这个调试过程充分展示了系统性问题排查的重要性，以及当多个技术组件交互时可能产生的复杂性。

问题现象

初始症状

在Django图片处理系统中，发现了一个奇怪的现象：

• AVIF请求：Accept: image/avif → 200 OK ✅
• JPEG请求：Accept: text/html → 404 Not Found ❌

同一张图片，仅仅因为客户端Accept头不同，就产生了完全不同的响应结果。

具体表现

# 支持AVIF的请求
curl -H "Accept: image/avif" "http://localhost:8500/static/images/test.jpg"
# 返回: 200 OK，成功转换为AVIF格式

# 普通浏览器请求
curl -H "Accept: text/html" "http://localhost:8500/static/images/test.jpg"  
# 返回: 404 Not Found

Prerequisites

• Ensure you have root or sudo access.
• A working internet connection to download source code and dependencies.
• Optional: Exit any Python virtual environment to avoid tool conflicts (deactivate if in a (venv)).

Steps

1. Install Build Dependencies
   Install the necessary tools and libraries for compiling libavif and its dependencies.

   sudo apt update
   sudo apt install -y build-essential cmake ninja-build libpng-dev libjpeg-dev yasm pandoc git libaom-dev
   

2. Clone the libavif Repository
   Download the latest libavif source code from GitHub.

   git clone https://github.com/AOMediaCodec/libavif.git
   cd libavif
   

问题概述: 在Vue 3 + Nuxt 3项目中，HTML5 <input type="range"> 元素在拖拽时 event.target.value 始终返回 0，导致音乐播放器进度条无法正常拖拽。本文记录了从问题发现到最终解决的完整调试过程。

📋 问题背景

在开发一个音乐播放器应用时，我遇到了一个看似简单但实际上非常复杂的问题：

现象:
- 用户拖拽进度条时，@input 和 @change 事件中的 event.target.value 始终返回 '0'
- 进度条视觉上可以拖动，但音频播放位置不会改变
- 点击进度条的特定位置可以正常跳转

技术栈:
- Vue 3.4+ (Composition API)
- Nuxt 3.17+
- TypeScript
- Pinia (状态管理)
- Tailwind CSS

🔍 问题调试历程

Phase 1: 初步分析 - "这应该很简单"

最初的组件实现看起来很标准：

<template>
  <input
    type="range"
    :min="0"
    :max="duration"
    :value="currentTime"
    @input="handleInput"
    @change="handleChange"
  />
</template>

<script setup lang="ts">
function handleInput(event: Event) {
  const target = event.target as HTMLInputElement
  const newTime = parseFloat(target.value) // ❌ 总是返回 0
  console.log('Input value:', target.value) // 输出: "0"
  emit('seek', newTime)
}
</script>

背景

在Azure Kubernetes环境部署的Sitecore网站中，我们遇到了一个棘手的静态资源缓存问题。尽管CSS和JS文件能被CDN正常缓存（返回TCP_HIT），但HTML文件始终返回TCP_MISS，导致性能下降和不必要的带宽消耗。

经过初步检查，我们发现CSS和HTML的响应头竟然完全相同：

# CSS响应头
HTTP/1.1 200 OK
Cache-Control: public, no-cache="Set-Cookie", max-age=31536000
Content-Type: text/css
Set-Cookie: website#lang=en; path=/; secure; SameSite=None
Set-Cookie: shell#lang=en; path=/; secure; SameSite=None
X-Static-CacheControl: true
...

# HTML响应头
HTTP/1.1 200 OK
Cache-Control: public, no-cache="Set-Cookie", max-age=86400
Content-Type: text/html
Set-Cookie: website#lang=en; path=/; secure; SameSite=None
Set-Cookie: shell#lang=en; path=/; secure; SameSite=None
X-Static-CacheControl: true
...

Reference

https://github.com/mikeedwards83/Glass.PublishViewer

Sitecore Version

Sitecore 10.4

Introduction

In Sitecore environments with large content databases and multiple publishing targets, publishing operations can sometimes take a very long time to complete. When a publishing job gets stuck or needs to be stopped for any reason, the standard approach has often been to restart the Content Management (CM) server - a disruptive and inefficient solution.

While Sitecore PowerShell Extensions (SPE) provides functionality to view and cancel queued publishing jobs, it doesn't offer a built-in way to terminate jobs that are already running. This post presents a comprehensive solution for safely terminating running publish jobs in Sitecore without restarting the server.

Understanding the Sitecore Publishing Architecture

Before diving into the solution, it's important to understand the key components of Sitecore's publishing architecture:

引用

https://github.com/yinxin630/fiora
https://github.com/yinxin630/fiora/blob/master/docker-compose.yaml
https://yinxin630.github.io/fiora/zh-Hans/docs/install#docker-%E8%BF%90%E8%A1%8C

docker-compose.yml 文件

services:
  mongodb:
    image: mongo
    container_name: fiora_db
    volumes:
      - ${PWD}/data/mongo:/data/db
    restart: always

  redis:
    image: redis
    container_name: fiora_redis
    volumes:
      - ${PWD}/data/redis:/data
    restart: always

  fiora:
    image: suisuijiang/fiora
    container_name: fiora
    ports:
      - "127.0.0.1:9200:9200"
    environment:
      - Database=mongodb://mongodb:27017/fiora
      - RedisHost=redis
      - Administrator=admin
      - DisableCreateGroup=true
    depends_on:
      - mongodb
      - redis
    restart: always

简介

Lsky Pro 是一款开源的图床程序，支持多种存储方式，提供了良好的用户界面和丰富的功能。本文将详细介绍如何使用 Docker Compose 来部署 Lsky Pro，这种方式相比传统安装更加简单和可维护。

引用

https://docs.lsky.pro/guide/install
https://www.cpolar.com/blog/casaos-uses-docker-to-build-lsky-pro-locally
https://hub.docker.com/r/dko0/lsky-pro
https://blog.laoda.de/archives/docker-compose-install-lskypro
https://github.com/lsky-org/lsky-pro/issues/256

环境要求

• Docker 20.10.0 或更高版本
• Docker Compose V2
• 2GB 或更多内存
• 域名（用于网络访问）
• Nginx（用于反向代理）

部署步骤

1. 创建项目目录

mkdir lsky-pro
cd lsky-pro

引言

Waline是一个简洁、安全的评论系统，支持多种部署方式。本文将介绍如何使用Docker独立部署Waline，并配置MySQL数据库来存储评论数据。通过Docker部署不仅简化了安装过程，还提供了更好的环境隔离和可移植性。

参考资料

https://waline.js.org/guide/database.html
https://bg3lnt.xyz/posts/dc23e930.html

先决条件

在开始部署之前，请确保您的系统满足以下要求：

• 已安装Docker和Docker Compose
• 了解基本的命令行操作
• 准备好域名和服务器（如需公网访问）

背景

在Sitecore内容管理中,经常会遇到需要批量创建多个相同模板项的情况。默认的Sitecore只支持一次创建一个项,这对于需要创建多个类似项(如卡片、图片等)的场景来说效率较低。本文将介绍如何扩展Sitecore的插入功能，实现一次性创建多个项的功能。

需求分析

基本需求

• 在现有Insert选项旁添加批量创建选项
• 允许用户指定基础名称和创建数量
• 自动处理项目命名和序号
• 处理名称冲突问题

技术要点

• 扩展Sitecore命令系统
• 创建符合Sitecore标准的对话框
• 实现智能命名策略
• 错误处理和用户反馈

实现方案

在Core库中创建menu

• /sitecore/content/Applications/Content Editor/Ribbons/Strips/Home/Multi New
  Reference : sitecore/content/Applications/Content Editor/Ribbons/Chunks/Multi Insert
• /sitecore/content/Applications/Content Editor/Ribbons/Chunks/Multi Insert (Copy from Insert)
• /sitecore/content/Applications/Content Editor/Ribbons/Chunks/Multi Insert/New
  Type : Sitecore.Foundation.SitecoreExtensions.Shell.Applications.ContentManager.Panels.CustomNewPanel,Sitecore.Foundation.SitecoreExtensions

引言

https://stackoverflow.com/a/55615885
https://community.chocolatey.org/packages/redis
https://redis.io/docs/latest/operate/oss_and_stack/install/install-redis/install-redis-on-windows/

在复杂的云原生环境中，确保各组件间的连接至关重要。本文将分享一个在Azure Kubernetes Service (AKS) 的Windows容器中测试Redis SSL连接的曲折历程，最终找到了一个出人意料的简单解决方案。

项目背景

我们的项目是一个基于ASP.NET的Sitecore应用，部署在Azure Kubernetes Service的Windows容器中。整个系统包含多个组件：

• 1个CM（Content Management）Pod
• 4个CD（Content Delivery）Pod
• 1个Redis Pod
• 1个Solr Pod
• 其他辅助服务