LOGO
首页 网站广场 站长动态 活跃度榜 审核查询 逛逛好站 留言交流 提交申请 关于本站

站长动态

站长动态所展示的是已加入好站网成员站长文章
共同步 2243 篇博文
(每2小时更新一次)
小十
入驻第1年
在 Hugo 中集成 Memos 多用户微博系统
摘要 本文详细阐述在 Hugo 静态网站生成器中集成 Memos 0.18.2 多用户微博系统的完整技术方案。通过 RESTful API 调用、Twikoo 评论系统集成、图片资源处理等关键技术,实现了在静态网站中展示动态微博内容的功能。本文涵盖系统架构设计、核心代码实现、性能优化策略以及部署配置指南,为开发者提供完整的实施参考。样例请见本站 说说页面 。 1. 主要流程 1.1 系统组成 前端框架: Hugo 静态网站生成器 微博服务: Memos 0.18.2 RESTful API 评论系统: Twikoo 评论服务 图片处理: ViewImage 灯箱 + Lozad 懒加载 内容渲染: Marked.js Markdown 解析器 1.2 数据流架构 Memos API → 数据获取 → 内容处理 → 评论统计 → HTML 渲染 → 前端展示2. 核心实现方案 2.1 多用户配置管理 在 Hugo 模板中定义用户配置数组: var memosMyList = [ { "creatorName": "用户A", "website": "https://example.com", "link": "https://memos.example.com", "creatorId": "1", "avatar": "/avatars/user-a.png", "twikoo": "https://twikoo.example.com" }, { "creatorName": "用户B", "website": "https://example.org", "link": "https://memos.example.com", "creatorId": "2", "avatar": "/avatars/user-b.png", "twikoo": "https://twikoo.example.com" } ]; 剩余 13 行代码 展开剩余代码 2.2 API 集成与数据处理 2.2.1 并发数据获取 async function getAllUsersMemos() { const userPromises = currentUsers.map(user => getUserMemos(user.link, user.creatorId, user.creatorName, user.avatar) ); const allUserResults = await Promise.allSettled(userPromises); const successfulResults = []; allUserResults.forEach((result) => { if (result.status === 'fulfilled' && Array.isArray(result.value)) { successfulResults.push(...result.value); } }); return successfulResults; } 剩余 11 行代码 展开剩余代码 2.2.2 数据验证与标准化 function validateUserConfig() { const validUsers = currentUsers.filter(user => user.creatorId && user.link && user.creatorName ); return validUsers.length > 0; } function normalizeUrl(baseUrl, path) { const normalizedBase = baseUrl.endsWith('/') ? baseUrl.slice(0, -1) : baseUrl; const normalizedPath = path.startsWith('/') ? path : '/' + path; return normalizedBase + normalizedPath; } 剩余 8 行代码 展开剩余代码 2.3 评论系统集成 2.3.1 批量评论统计 async function getMemoCount(memos) { const twikooGroups = {}; // 按 Twikoo 环境分组处理 memos.forEach(item => { if (!item?.twikoo) return; const envId = item.twikoo; const memoUrl = normalizeUrl(item.link, `/m/${item.id}`); if (!twikooGroups[envId]) { twikooGroups[envId] = []; } twikooGroups[envId].push({ url: memoUrl }); }); const allTwikooCount = []; for (const [envId, items] of Object.entries(twikooGroups)) { try { const urls = items.map(item => item.url); const res = await twikoo.getCommentsCount({ envId: envId, urls: urls, includeReply: false }); if (Array.isArray(res)) { allTwikooCount.push(...res); } } catch (error) { console.error(`Twikoo 环境 ${envId} 评论数获取失败:`, error); } } // 关联评论数到对应 Memo memos.forEach(item => { if (!item?.twikoo) { item.count = 0; return; } const url = normalizeUrl(item.link, `/m/${item.id}`); const countData = allTwikooCount.find(o => o?.url === url); item.count = countData?.count || 0; }); return memos; } 剩余 44 行代码 展开剩余代码 2.4 内容渲染引擎 2.4.1 Markdown 内容处理 function processMemoContent(content) { const TAG_REGEX = /#([^#\s!.,;:?"'()]+)(?= )/g; const IMAGE_REGEX = /\!\[(.*?)\]\((.*?)\)/g; const LINK_REGEX = /(?<!!)\[(.*?)\]\((.*?)\)/g; let processed = content .replace(TAG_REGEX, '') .replace(IMAGE_REGEX, '') .replace(LINK_REGEX, '<a class="primary" href="$2" target="_blank">$1</a>'); return marked.parse(processed); } 剩余 7 行代码 展开剩余代码 2.4.2 图片资源处理 function processImageResources(content, memo) { let imageHtml = ''; // 处理内联图片 const inlineImages = content.match(IMAGE_REGEX); if (inlineImages?.length > 0) { const imageString = inlineImages.join('').replace(/,/g, ''); imageHtml = imageString.replace(IMAGE_REGEX, '<div class="memo-resource width-100">' + '<img class="lozad" data-src="$2" alt="$1">' + '</div>' ); } // 处理附件图片 if (memo.resourceList?.length > 0) { memo.resourceList.forEach(resource => { if (resource.type?.startsWith('image')) { const imageUrl = resource.externalLink || normalizeUrl(memo.link, `/o/r/${resource.uid || resource.id}`); imageHtml += '<div class="memo-resource w-100">' + '<img class="lozad" data-src="${imageUrl}">' + '</div>'; } }); } return imageHtml ? '<div class="resource-wrapper">' + '<div class="images-wrapper my-2" view-image>' + imageHtml + '</div>' + '</div>' : ''; } 剩余 27 行代码 展开剩余代码 3. 性能优化策略 3.1 分页加载机制 function pagination(data, page, limit) { const startIndex = (page - 1) * limit; const endIndex = startIndex + limit; return data.slice(startIndex, endIndex); } function updateData(data) { const validData = data.filter(item => item && typeof item === 'object'); validData.sort((a, b) => b.createdTs - a.createdTs); const pageData = pagination(validData, currentPage, itemsPerPage); renderMemoList(pageData); const totalPages = Math.ceil(validData.length / itemsPerPage); updatePaginationControls(currentPage, totalPages); } 剩余 11 行代码 展开剩余代码 3.2 图片性能优化 function initializeImageOptimizations() { // 图片懒加载 if (typeof lozad !== 'undefined') { const imageObserver = lozad('.lozad', { rootMargin: '50px 0px', threshold: 0.1 }); imageObserver.observe(); } // 图片灯箱初始化 if (typeof ViewImage !== 'undefined') { ViewImage.init('.images-wrapper img'); } } 剩余 10 行代码 展开剩余代码 3.3 缓存策略 class MemosCache { constructor() { this.cacheKey = 'memos-data-cache'; this.cacheTimeout = 5 * 60 * 1000; // 5分钟 } getCachedData() { const cached = localStorage.getItem(this.cacheKey); if (!cached) return null; const { data, timestamp } = JSON.parse(cached); if (Date.now() - timestamp > this.cacheTimeout) { localStorage.removeItem(this.cacheKey); return null; } return data; } setCachedData(data) { const cacheObject = { data: data, timestamp: Date.now() }; localStorage.setItem(this.cacheKey, JSON.stringify(cacheObject)); } } 剩余 22 行代码 展开剩余代码 4. 错误处理与监控 4.1 健壮性设计 async function getUserMemos(link, userId, userName, userAvatar) { try { // 参数验证 if (!link || !userId) { throw new Error('缺少必要参数'); } const normalizedLink = link.endsWith('/') ? link : link + '/'; const apiUrl = `${normalizedLink}api/v1/memo?creatorId=${userId}&rowStatus=NORMAL&limit=50`; const response = await fetch(apiUrl); if (!response.ok) { throw new Error(`HTTP ${response.status}: ${response.statusText}`); } const data = await response.json(); if (!Array.isArray(data)) { throw new Error('API 返回数据格式错误'); } return data.filter(item => item && typeof item === 'object') .map(item => ({ ...item, link: normalizedLink, avatar: userAvatar, creatorName: userName })); } catch (error) { console.error(`获取用户 ${userName} 数据失败:`, error); return []; // 优雅降级 } } 剩余 29 行代码 展开剩余代码 4.2 性能监控 class PerformanceMonitor { static async measureApiCall(apiCall) { const startTime = performance.now(); try { const result = await apiCall(); const duration = performance.now() - startTime; if (duration > 1000) { // 超过1秒记录警告 console.warn(`API 调用耗时较长: ${duration.toFixed(2)}ms`); } return result; } catch (error) { const duration = performance.now() - startTime; console.error(`API 调用失败,耗时 ${duration.toFixed(2)}ms:`, error); throw error; } } } 剩余 14 行代码 展开剩余代码 5. 部署配置指南 5.1 文件结构规范 hugo-site/ ├── layouts/ │ └── _default/ │ └── memos.html ├── static/ │ └── memos/ │ ├── js/ │ │ ├── memos-core.js │ │ ├── twikoo.min.js │ │ ├── marked.min.js │ │ └── lozad.min.js │ └── css/ │ └── memos-styles.css └── content/ └── memos.md 剩余 10 行代码 展开剩余代码 5.2 Hugo 模板配置 <!-- layouts/_default/memos.html --> {{ define "main" }} <div class="memos-container"> <header class="memos-header"> <h1>{{ .Title }}</h1> </header> <div class="memos-content"> <div id="memo-list" class="memo-list-container"></div> <button id="load-more" class="load-more-button">加载更多</button> </div> </div> <script src="/memos/js/marked.min.js"></script> <script src="/memos/js/lozad.min.js"></script> <script src="/memos/js/twikoo.min.js"></script> <script src="/memos/js/memos-core.js"></script> {{ end }} 剩余 13 行代码 展开剩余代码 5.3 环境变量配置 // 生产环境配置 const MEMOS_CONFIG = { apiEndpoints: { memos: 'https://memos.example.com/api/v1', twikoo: 'https://twikoo.example.com' }, performance: { cacheTimeout: 300000, paginationSize: 10, imageLazyLoad: true }, features: { multiUser: true, comments: true, imageZoom: true } }; 剩余 12 行代码 展开剩余代码 6. 安全考虑 6.1 输入验证 function sanitizeUserInput(input) { if (typeof input !== 'string') return ''; return input .replace(/</g, '&lt;') .replace(/>/g, '&gt;') .replace(/"/g, '&quot;') .replace(/'/g, '&#x27;') .replace(/\//g, '&#x2F;'); } 剩余 5 行代码 展开剩余代码 6.2 CSP 配置建议 <meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' https://memos.example.com https://twikoo.example.com; img-src 'self' https: data:; style-src 'self' 'unsafe-inline'; connect-src 'self' https://memos.example.com https://twikoo.example.com"> 剩余 1 行代码 展开剩余代码 7. 测试方案 7.1 单元测试示例 describe('Memos Integration', () => { test('URL normalization', () => { expect(normalizeUrl('https://example.com/', '/m/123')) .toBe('https://example.com/m/123'); expect(normalizeUrl('https://example.com', 'm/123')) .toBe('https://example.com/m/123'); }); test('Content processing', () => { const input = 'Hello [world](https://example.com)'; const processed = processMemoContent(input); expect(processed).toContain('href="https://example.com"'); }); }); 剩余 10 行代码 展开剩余代码 8. 结论 本文提出的 Hugo 与 Memos 多用户微博系统集成方案,通过系统的架构设计和严谨的代码实现,成功在静态网站环境中引入了动态社交功能。关键技术贡献包括:
雅余
入驻第1年
日常漫步 Vol.17 之板樟山小环线
又是一个完美的周末,一周两山。继周六上午到凤凰山巡山之后,感觉没过瘾,周日下午4点又到板樟山走了个小环线,一直 […]
老刘
入驻第1年
把GotoSocial嵌入到Hugo
把博客重新换成Hugo后,我又把GotoSocial安装了起来,就是想发布自己有一些碎语之类的东西,在memos和GotoSocial中纠结了一会,最终选择了GotoSocial,主要原因还是看到memeos的作者随意改动API,为了以后不再有不必要的麻烦,还是选择一个更稳定的最好。整体完成后的效果可以参考: 我的微博 总体思路 由于 GoToSocial 默认开启了严格的 CORS 限制,获取内容的时候需要token,由于Hugo是静态博客,直接把token写在齐物非常不安全,所以我们需要一个中转层。 Cloudflare Workers 可以完美胜任代理转发的功能,作用是: 从 Hugo 齐物发请求 → Cloudflare Worker Worker 向 https://你的域名/api/v1/accounts/…/statuses 请求 GoToSocial 数据 Worker 再把 JSON 数据返回给 Hugo 齐物 Hugo 构建时渲染 获取 GoToSocial 的 toot API 接口 目标概述 我们要: 向 https://你的域名/api/v1/apps 注册一个应用; 通过浏览器授权; 用授权码换取 access_token; 把这个 token 放入 Cloudflare Worker 的环境变量; 然后 Hugo 博客就能安全地从 Worker 获取嘟文数据。 详细步骤 注册一个新应用 在命令行执行以下命令(用 curl,别忘了改你的 app 名称): curl -X POST \ -H "Content-Type: application/json" \ -d '{ "client_name": "hugo-gts-proxy", "redirect_uris": "urn:ietf:wg:oauth:2.0:oob", "scopes": "read" }' \ 'https://你的域名/api/v1/apps' 成功后会返回类似:
陈仓颉
入驻第1年
和平使者不和平
滚导有一种神奇的能力,能把边缘反英雄拍出丰富、动人的情感,也能把一个好 IP 拍成一坨屎。后者自然是《新超人》 […]
JN
入驻第1年
部落格問題挑戰
前幾天看到廢文小天地發了一篇 部落格問題挑戰 看了覺得好像蠻有趣的,我就也來挑戰一下吧~ 你當初為什麼開始寫部落格? 最一開始應該是受到 Wiwi 在 好檸檬 Podcast 的熏陶。那時候我還在讀大四,沒有什麼課要上,但有點求職焦慮。覺得自己會的東西不多,不如就先開始寫部落格吧!所以那個時候寫的東西也都以技術、作品展示居多。(然而其實根本沒什麼好寫,我也根本沒有我想的那麼弱) 我在 過去寫的是廢文、那今天的新文章是……? 有比較詳細地回顧我的部落格。 使用什麼平台來管理你的部落格?為什麼選擇它? 我用的是 Hugo SSG(靜態網頁産生器),佈景主題是 Stack,部署在 Cloudflare Pages 上。 用 Hugo 是因為有不錯的開源佈景主題可以用,要客製化元件也還算容易。另外選擇 SSG 的好處是不太需要煩惱部署 & 維運的事情,甚至可以達成 0 元架站!這讓我能把心思盡量放在寫文章這件事情上。 我在 部落格大搬家:從 Wowchemy 到 Stack 這篇文章有提到比較多關於我最近這次搬家的選擇。 之前有在其他平台上寫過部落格文章嗎? 很久以前有,很小的時候在無名小站有寫過一些東西。不過那個時候大家都還沒開始用 Facebook 就是了,我覺得和現在的部落格不太能相題並論,我那個時候應該也沒有寫什麼值得挖出來的東西。 除了在這邊,我之前也會把文章同步到 Medium、Matters 之類的平台,不過後來就懶了。 (BTW,安安Q 的女裝日記 也是我的另一個部落格,主要記錄和女裝相關的主題) 如何撰寫文章?例如,使用本地編輯工具,還是在部落格的後台/控制面板中編寫? 我用的是 VSCode,搭配 Front Matter(Ivon 的介紹) 就有一個還可以的管理介面! 選擇 VSCode 是因為我寫 code 就已經很習慣了,而且還能整合 AI 直接在編輯器裡面幫我修我的文章!我真的找不到第二個這麼好用的純文字編輯器!(寫 code 的話 Vim 還能與之一戰) 不過 VSCode 也有一個缺點,就是只能在電腦上用。 所以如果我不方便用電腦的時候,我會先在手機上用 LogSeq 先打草稿,然後在能用電腦的時候再貼到 VSCode 裡面把文章編輯之後再發出來。 什麼時候最有寫作靈感? 我的靈感大部分都來自上班無聊的時候生活中事件的記錄。所以我在發現有事情可以寫成文章的時候就會先記到我 LogSeq 裡面;在我之後有空的時候,就會看看有什麼之前的筆記有什麼東西可以寫,或是記一下最近發生了什麼事情。 有的時候其他部落格的文章也會是我的靈感來源,就像這篇文章;或者 Meta 惹毛我的時候我也會有很多靈感。 會在寫完後立即發布,還是會先存成草稿醞釀一下? 通常我在文章寫完之後就會直接發出來。 不過有時候可能因為要補圖片之類的原因,可能就會把文章擺個幾天再發;或是如果那陣子發文比較密集的話,我也可能會為了想要分散一下更新頻率,把文章放個幾天再發出來。 部落格上最喜歡的文章是哪一篇? 老實說我選不太出來,因為我覺得我的每一篇文章都還不是很成熟。但如果真的要選一篇的話,那會是 我把洛克人 X4 全破了!。 因為我覺得這篇文章完整地把我玩落克人的開心、以及為什麼喜歡這個遊戲都記錄了下來。我也覺得這篇應該會是在未來,我會一直回去回味的一篇文章。 對部落格有什麼未來計畫嗎?例如重新設計、搬到另一個平台,或是加入新功能? 短期內我會想要先多累積一些文章吧,也許 50 或 100 篇之類的。一是我想讓我自己再更習慣寫文章這件事情;二是我也想再觀察看看什麼樣的內容比較能收到比較多的回饋(尤其是來自現實的朋友),畢竟那也是維持寫作的一大動力!所以現階段來說可能比較像是我的部落格的探索期吧~ 在我的部落格的類型脈絡比較清晰、文章也多到不容易翻的時候,我可能會需要建一個引導頁來讓新來的朋友比較不會迷路。如果之後找到有什麼是大家特別喜歡看的,而且我也有想要特別經營的話,也許我也會另外拉成一個獨立的站也說不定。 如果不知道寫什麼的時候,我也可能把社群平台上面的貼文慢慢搬過來(那些平台能再活幾年都是未知數);或者我也可能當一個臭老人,一直把以前的事情挖出來寫 XD 至於加入新功能什麼的,暫時沒有太多想法,目前覺得蠻夠用的。如果要說最可能改的東西的話,也許是把留言板系統好好設定一下吧,現在有一些地方還是怪怪的;另外也可能會加的新功能,是把 Mastodon 的貼文內嵌或同步到這個部落格的某個角落。因為我還是有一些比較短的廢文會發在那邊,如果能在這邊一起看到的話感覺蠻棒的~ 結語 部落客之間的互相影響,是我覺得寫部落格很有趣的事情之一。這種感覺很像 10 年前的 YouTube,創作者之間會互相 feat. 來 feat. 去的,互相打通彼此的觀眾,擴大彼此的影響力。 這種真人之間的互相交流,比起在一些平台上看不知道是誰(甚至可能不是人類)的貼文,搞不好還比較能被稱作是「社群」。
小十
入驻第1年
借助 GitHub Actions 自动化部署 Hugo 网站到自有服务器
从手动部署到自动化的工作流演进 在网站开发的初期阶段,为了深入理解整个发布流程,我一直在本地环境中使用 Hugo 手动生成静态网站。这个过程包括:运行 hugo 命令生成静态文件,手动打包 public 目录,然后通过 SCP 或 FTP 上传到服务器,最后在服务器上解压并配置。虽然这种方法让我对网站部署的每个环节都有了清晰的认识,但随着内容的增多,这种重复性工作变得越来越耗时。 虽然现在有 Vercel、Netlify 等优秀的静态网站托管平台,但由于我已经拥有一台国内的轻量级云服务器(主要用于 frp 内网穿透服务),我决定充分利用现有资源,直接在这台服务器上托管我的 Hugo 网站。 自动化部署方案设计 最终实现的解决方案是:通过 GitHub 私有仓库存储 Hugo 源码,利用 GitHub Actions 实现自动化构建和部署,使用 rsync 将生成的静态文件同步到自己的服务器。 这种方案的优势在于: 自动化:代码推送后自动完成整个构建和部署流程 版本控制:所有变更都有完整的历史记录 安全性:私有仓库保护源代码,SSH 密钥保证传输安全 成本效益:充分利用现有服务器资源 服务器端配置 环境准备 我使用 1Panel 面板管理服务器,网站目录为: /opt/1panel/apps/openresty/openresty/www/sites/xiaoten.com/index安装 rsync 由于同步方案使用 rsync,需要在服务器上安装: # CentOS/RHEL 系统 sudo yum install -y rsync # Ubuntu/Debian 系统 sudo apt-get update && sudo apt-get install -y rsync安全配置:SSH 密钥认证 为了实现安全的自动化部署,需要配置 GitHub Actions 对服务器的访问权限。
太隐
入驻第1年
棱镜通讯 No.116 诺兰·布什内尔(Nolan Bushnell)
不断思考如何做得更好,并质疑自己
太隐
入驻第1年
我们在造神运动中,失去的是理性与常识
谁在神化达芬奇?
乌托邦
入驻第1年
WSL update时报错403的解决方案
背景 无论你是需要使用Ubuntu WSL还是需要使用Docker Desktop,你都需要先开启WSL。但是,如果你使用的是Windows 11 Pro最近的几个版本,例如25H2或者24H2,那么你首次开启虚拟化后安装WSL时几乎必定会发生如下的报错: PS C:\Users\XXX> wsl --set-default-version 2 适用于 Linux 的 Windows 子系统必须更新到最新版本才能继续。可通过运行 “wsl.exe --update” 进行更新。 有关详细信息,请访问 https://aka.ms/wslinstall 按任意键安装适用于 Linux 的 Windows 子系统。 按 CTRL-C 或关闭此窗口以取消。 此提示将在 60 秒后超时。 已禁止(403)。 这个时候如果你在搜索引擎搜索,网络上的大部分教程会告诉你,这是因为网络问题或权限问题,导致系统无法自动下载WSL2的更新包,你需要到https://learn.microsoft.com/zh-cn/windows/wsl/install-manual#step-4---download-the-linux-kernel-update-package去下载WSL2 Linux内核更新包并手动安装。 这个步骤似乎没错,你将wsl_update_x64.msi下载下来并安装,那么这个时候你会遇到第二个问题:安装程序报错弹框This update only applies to machines with the Windows Subsytem for Linux,然后安装程序就退出了。 这会儿你肯定已经懵逼了,更新包的安装程序说我的电脑上没有WSL,那我刚刚运行的命令是什么?然后你就会去检查自己是不是真的开了WSL功能和虚拟机平台,就算你去问 AI 它也大概率告诉你的是要求你去再次检查是否已经开启那两项功能并且已经重启。一切就此卡住。 原因 先说原因吧,导致上面的问题的罪魁祸首有两个: wsl.exe --update 的“403 已禁止”报错,基本可以确定是系统无法访问微软商店/相关内容分发节点(被企业策略、WSUS、代理或地区网络限制),这在中国大陆地区很常见。 在Windows 11的最新几个版本中,WSL已经改为通过微软商店包分发(Store 版 WSL),老的内核 MSI 仅适用于“inbox 版”WSL,检测到你不是该通道或检测不到对应组件时自然就会拒绝安装。 因此,你根据网络上的教程去手动下载的更新包实际上是与你的系统不匹配的。 解决办法 方法A:离线安装 Store 版 WSL 包 我更推荐这种方法,手动安装能够避免自动安装过程中带来的网络问题。 去Github上下载最新版本的WSL的安装包(.msixbundle):https://github.com/microsoft/WSL/releases,文件名类似这样Microsoft.WSL_xxx_x64_ARM64.msixbundle。 直接双击打开安装包安装即可。 安装好之后你再去wsl --set-default-version 2就会发现一切正常了。 方法B:绕过微软商店更新通道 说实话不建议使用这种方法,因为即便你能够成功连接到Github,在国内直连下载文件的速度也会超级慢。 以管理员权限打开 PowerShell,执行: wsl --update --web-download 这条命令会直接从 GitHub 的 WSL 发布页下载并安装,而不是走微软商店/CDN,通常能绕过 403 问题。 成功后执行: wsl --set-default-version 2 再运行 wsl --version 和 wsl --status 看看是否已显示内核版本、WSL 版本。
JN
入驻第1年
台中市 114 年替代役 EMT-1 演訓召集(教召)分享
安安各位替代役青年們~ 小娣很幸運收到役政司的邀(ㄑーㄤˊ)請(ㄆㄛˋ)回去複訓 EMT-1,趁著上課的空檔,就把整個過程記錄下來分享給大家好了。不希望大家用到,但希望給需要的人一些參考! 小娣的戶藉在台中大里區,演訓(教召)期間的地點是在龍井區公所。 時間則是 114(2025)年 10 月 14 ~ 17 日,總共 4 天。 收通知書 & 召集令 在集合的前一個多月之前,公所會派人送「通知書」到你家(戶藉地),家裡如果沒人在的話他會打電話給你,如果真的沒人可以收的話就需要自己或家人跑一趟公所去領。 這個「通知書」只是通知你準備,上面還不會有集合的日期,只有一個期限,如果在那之前都沒有收到召集令的話,那就是沒有中獎。 我這次的召集類型是「EMT-1」複訓,每天來回不用住宿。據說還有實彈射擊、或是其他可能要過夜的演訓。 大概過一個禮拜之後,就會用一樣的方式把「召集令」送到你家裡,這次就是有寫清楚時間的正式通知了。 除了召集令以外,我還有收到一張注意事項,上面有時間、地點、薪奉、聯絡方式之類的資訊。比較需要注意的我都整裡在下面。 事前資料傳送 在集合之前,會需要提前傳送兩樣資料給公所: 郵局存摺封面影本:領錢用,只接受郵局。如果有行動郵局 App 的話,可以從 帳戶 > 存簿 > 帳號資訊 下載電子版存摺封面。 服務證明:如果你因為工作等等原因需要從外縣市往返的話,可以申請交通費。需要跟服務單位(公司)申請服務證明,可以去問問公司的 HR 怎麼申請。如果你沒有要申請交通費的話就不用附。 我這邊的公所有提供傳真和 email 兩種方式。我寄 email 過去之後,公所的科員有回覆我已經收到,如果沒有的話也可以打個電話過去確認。 能不能出國? 因為我在召集前會去日本玩一趟,所以我就和公所確認了一下如果要出境的話會不會有問題。 而答案是:只要時間沒有重疊,就沒有問題!也不需要申報什麼的,我那時候在出境也沒有遇到任何問題~ 當天集合 當天需要攜帶的東西有:召集令、身分證、印章、服務證明(通知上面有寫健保卡但其實用不到)。 集合的地點是公所,因為召集的地點是在遠的要命的台中龍井(我家住大里),集合時間是 7:40,真的是頗早。 我提早十分鐘到公所報到,但我到的時候隊伍已經很長了,目測有個 4、50 人吧,比想像中的還多得多。也許是大家都是社會人士了吧,大家該排隊就排隊,該幹嘛就幹嘛,也不太吵鬧,也許這就是社畜的無聲吶喊(X 公所包了兩台遊覽車載我們過去龍井,我坐的這車坐了 39 人,所以我猜我們區總共差不多是 75 人左右吧。 從大里到龍井的車程差不多要快一個小時。基本上在車上大家也不太說話(早起真的很累),可以善用這個時間補眠一下。 禮堂 演訓地點是在公所的五樓。下車之後等自己區的科員或是學弟點完人數之後就會帶隊上樓,而且可以坐電梯上去,還算蠻有人性的。 到了禮堂之後,椅子上就放著這四天檢要穿著的背心、識別證、還有送的一個手提袋(?)。那邊的冷氣還算冷,如果有很怕冷的朋友可以帶一件外套。 這次演訓總共是 280 人,有蠻多個區都有來的。但不知道為什麼我們大里的人特別多,每次要領便當還是簽到簽退的時候就要等很久 QQ 禮堂外面走廊有提供飲用水和瓶裝水,這方面不用太擔心;不過禮堂內原則上是不能喝飲料的,需要到走廊喝,如果想帶飲料的話可能就要斟酌一下。 第一天有開訓典禮,但基本上就是請長官來講講話而已,不用唱國歌升旗,當然也不用在那邊擺頭還有拍手部隊。 上課 每天的第一堂課基本是在等大家到齊,所以是坐著聽的靜態學科課。除了一些急救知識,也有一些廢話民防通識、以及替代役召集的相關權利和義務。 上課期間不管手機的使用,基本上不要太沒禮貌都無所謂,所以要做筆記或是像我這樣一邊記錄分享都是沒問題的。 雖然現場有擺著流程表,但幾乎沒有照著這個進行,看看就好。 除了靜態課程以外,當然也有實際操作的訓練。前三天會各學五個科目,總共十五個。 而進行方式是分成 5 組,在禮堂裡面輪流進行,由台中市消防局的教官來上課。這幾天要長時間坐或跪在地上,屁股真的是會蠻痛的,如果可以的話建議穿厚一點的長褲會比較適合。 課程之間都有 5 ~ 10 分鐘不等的休息時間,有需要抽菸的朋友可以利用這個時間。 午餐 因為禮堂不能飲食,所以午餐是到一樓的大廳用餐。 拿到了便當就去拿塑膠椅找個順眼的朋友一起坐著吃飯,但沒有桌子所以要端著吃。 菜色的話大概是這個樣子(一天比一天差): 午休的時間蠻長的,至少都有一個小時。蠻多人會去公所對面買飲料,或是去便利商店買個小點心,也可以在禮堂地上趟著睡覺。 解散 每天的大約 4 點半,就會準備解散,搭遊覽車回到原公所,在車上還會發一個餐盒。 因為四天的餐盒都幾乎一模一樣,我就不另外拍了。 值得吐槽的是:一天的餐費是 $168,而這個餐盒當然是包含在這個費用裡面。不把這個預算拿去訂好吃一點的午餐,不知道到底是有什麼特別的理由 @@ 補充:有朋友問過能不能直接離開,不要搭遊覽車回去公所。 答案是不行。 大量傷患演練 課程在前三天就都上完了,為的就是最後一天的災(ㄆㄞ)害(ㄓㄠˋ) 演(ㄧㄢˋ)練(ㄕㄡ)。 這個演練主要在樓下的廣場進行,會需要大家運用幾天學的去幫傷患搬運、處置。 教官會指定每組的某些人是紅、黃色,然後其他的每 3 個一組猜拳決定出綠色,剩下的就是在現場協助救災的人們。 而流程基本上就是:把綠色從禮堂扶到樓下 -> 把紅、黃色搬一搬 -> 做正確的處置。 因為外面很熱,教官們也都不想搞得太麻煩,所以其實整個演練很快就結束了。算上前面的解說、分組、準備,整個演練應該只花了一個多小時而已,然後就開開心心上樓吹冷氣了。 結訓 最後一天演練結束、午休完了以後,就是最後的結訓典禮。 結訓典禮也跟開訓典禮一樣,就是聽長官講話而已。比較特別的是還有頒發績優召員獎,我們這次的承辨是直接當抽獎抽掉了。不過我沒有認識抽到的人,所以那個獎品是什麼我就不太清楚了。 結訓典禮完,領完該領的東西之後,時間大概來到下午 2 點,這時候就可以準備坐車閃人了! 結語 老實說,我覺得這整次的召集,就是你配合我、我配合你的去完成大家都有的義務而已,沒什麼特別不合理或是刁難的地方;如果有在公司上班的話,甚至還可以請公假領兩邊的錢,也有外地的交通費補助,我覺得就當做是去那邊見見同梯或是交交朋友啦。 而上課的內容,雖然不能維持 EMT-1 的效期,這輩子也不太有機會實際去救患者。但內容有相當部分是在講在急救員到現場以前,我們可以如何自救或是救親朋好友。如果稍微花點心思去聽的話,還是很有幫助的。 我覺得這次的召集就是帶著平常心,順順地就過了,沒有太多需要特別注意的地方。只要按照公所的文件、提醒去準備,就沒有太大問題! 這次召集的分享就差不多到這邊,希望能幫助到下次要去召集的替代役青年們~
阿川
入驻第1年
知乎答疑:个人博客内容常陷入同质化,如何找到独特风格?
JN
入驻第1年
這個部落格開始步上正軌了
在這個部落格的首頁右側有一個文章計數器,會顯示每年的文章各有多少篇。 如果仔細看一下的話,我在 2022 + 2023 年總共寫了 19 + 4 = 23 篇;今年則是 24 篇。也就是說,我從今年七月底開始回來寫部落格,這三個月內寫的文章就比之前兩年間寫的文章還要多了。 我自己覺得這個過程在我自己身上的改變還蠻明顯的。我現在已經養成了寫作記錄生活和各種想法的習慣,這對我這個很懶得記錄的人來說蠻難得的,尤其我也不太喜歡被記錄的行為(拍照之類的)打斷我當下的沉浸,這種事後再回顧寫文的方式是比較適合我的方式。通常我也會用比較長的篇幅,社群平台通常也裝不下那麼多內容,上面的人也懶得看,部落格文章果然還是比較合適的型式。 另外,最近現實也越來越多朋友跟我提到我在部落格寫的東西,甚至有一些是交流不多的朋友,這真的讓我蠻意外的。也許,這也代表這樣的型式對於不太熟悉我但願意深入了解的人算是友善的,我也對於能吸收一些願意跨出社群平台的人感到開心! 能和其他的部落客(好久沒用這個詞了)交流也是蠻有趣的事情,這和在主流社群平台上的那種速食博眼球的文化不同。在這邊寫東西雖然能看到的人不見得比較多,但來這邊的人更願意把文章慢慢地看完,也更容易有比較深度的交流。 不只如此,讀其他人的部落格和在看社群平台上的貼文也是不一樣的感覺──那種透過字裡行間感受到這是一個活生生的人寫出來的完整故事,又或者是對於事情有個人獨特的見解、敘事方式,都讓我願意在 RSS reader 把這些人的文章一篇一篇都打開來讀。即便那是與我完全無關的個人生活記錄,也讓我這個局外人獲得很多的樂趣。 總而言之,雖然寫個人部落格在 2025 年看起來可能是吃力不討好的事情,但這已然成為我生活的一部分,而且我也覺得這是一件值得做的事。我也不曉得我能夠持續在這個部落格寫多久,只希望當下一次我停更的時候,不要像是 過去的兩次 一樣,而是找到了更值得去做的事。
小十
入驻第1年
终于初步完成了从Typecho到Hugo的网站迁移
整体历程 2011年2月2日,本站启用并使用WordPress; 2021年7月29日,从WordPress迁移至Typecho; 2025年10月16日,终于正式把域名指向到了Hugo生成的静态页面。 主要过程 因为涉及到html转markdown,使用自动化的转换工具带了一些排版混乱、不合理的转义等等,本来想仿照有些博主,写个脚本自动优化,但随后又转念一想,还是都过一遍吧,于是在工作中见缝插针,以及下班后沉浸到半夜,持续两天枯燥的html转markdown的过程。 虽然当时WordPress转Typecho时已进行了一些格式上的适配,但这次回过头看,问题特别多。 因此还是启用了21年转Typecho时wordpress的备份,好在迁移到Typecho,并没有写过几篇文章,迁移到Typecho以后的文章手动添加就好了。 静态博客生成工具的确定 决定采用静态博客的目的,还是想学习现在的博客主流模式,让更多的注意力在写作本身上面,摆脱臃肿的博客程序,虽说typecho已经非常轻量了,但可能是使用主题的问题,总会有遇到各种各样的使用问题,自身也没有精力去学着去写一个精简的主题,另外静态博客可以很方便的托管到一些GitHub等这样的一些开源平台上,不用再受制于服务器等这些问题。 目前,整个的服务器都已迁移到家庭的nas里,通过购买阿里云的轻量云服务器仅用来内网穿透+反向代理使用,整体成本很低。 除了个人博客这个站点以外的其他网站应用或服务应用还得依托于家里的服务器。 经过浏览了多个业内大佬的网站之后,发现Hugo的覆盖率还挺高,另外Hugo官网的一些主题也都是偏简洁的风格,在B站看了Hugo的实现原理及教程,也很容易上手,因此确定了Hugo作为生成工具。 Hugo模板的确定 最终在官网上对比了几个比较主流的模板之后,最终目光还是集中在了一个比较简洁的一个主题: Hugo blog awesome 。 决定开始使用这个主题是在10月11日,截至写这篇文章已经调试使用了5天时间,目前整体使用起来没有大的问题,但还是有一些自己不满意且比较棘手的问题。不知道后续会不会再换模板,目前先这样用着。 字体 在原有模板的基础上应用了思源宋体,并通过 cn-font-split 实现了字体切割,实现网页字体的快速加载。 分页功能 另外想通过hugo自带的分页功能实现文章列表的分页,但尝试很多种方法,并借助deepseek都没有办法实现。因此最终通过了JavaScript脚本实现了分页功能,这个看后续有没有更好的解决办法。 已解决分页问题,详见文章: 解决 Hugo 分页器返回空页面的诡异问题:.Paginate 不能被多次调用 。 全文搜索 静态博客如果想实现全文搜索,方法也比较多,我采用了比较成熟的工具: Pagefind 。 代码高亮的自动转换 默认hugo自带的代码高亮功能,一般只能设置一个样式,固定下来之后,不管主题是白色还是黑色,都是统一的一个代码高亮样式,为了实现白色/黑色主题切换时代码高亮主题也自动进行更换,通过脚本实现不同主题下不同的代码高亮方案。 识别外部链接自动启用新窗口打开 通过在layouts/_default/_markup/目录下创建render-link.html文件,并写入代码: {{ $url := urls.Parse .Destination }} {{ $isExternal := eq $url.Scheme "http" "https" }} <a href="{{ .Destination | safeURL }}" {{ if $isExternal }}target="_blank" rel="noopener noreferrer"{{ end }} {{ with .Title }}title="{{ . }}"{{ end }}> {{ .Text | safeHTML }} </a> 剩余 3 行代码 展开剩余代码 实现自动识别非本站链接采用新窗口打开的功能。
平凡
入驻第1年
阿凡货源商城-记得收藏不迷路哦!
阿凡货源商城:http://sc.hzyo.cn/阿凡商城是一个线上购物网站,你应该可以在里面找到你需要的商品哦!
老刘
入驻第1年
禅让制度以及无为的再思考
最近阅读南怀瑾先生的《禅宗和道家》,书中关于上古史的一些观点引起了我深深的思考。他提到,帝尧是黄帝的曾孙,大禹则是黄帝的玄孙。 禹的儿子子启建立夏朝,开启了中国的“家天下”时代。 从这个角度来看,夏朝的建立,似乎也承继了黄帝的血脉和基业,在某种意义上,称之为黄帝家族的延续也未尝不可。 禅让制:实力与贤德的交织? 这就引出了一个关于古代禅让制度的疑问。传说中尧曾想将位子禅让给许由,但许由拒绝了,这种高洁的精神境界固然令人敬佩,但传说毕竟是传说。 古代的禅让,真的仅仅是“禅贤”吗?从尧、舜、禹的血缘关系和历史记载来看,禅让的对象往往是有实力的部落或部落联盟的首领。例如,舜在被禅让前,已是一位拥有四方部落支持的首领。因此,即使是在被推崇为“天下为公”的禅让时代,“贤德”固然是重要的衡量标准,但“实力”和“政治影响力”恐怕也是不可或缺的砝码。 贤德需要实力的支撑,才能真正实现治理天下的抱负。 历史课本对“无为”的误解与“消极”的标签 第一次接触“无为”,是在初中历史课本上。课本将老子的思想概括为“消极”,用“小国寡民”、“鸡犬之声相闻,老死不相往来”来论证其“退步”和“与世隔绝”。那时候,我对课本的观点深以为然。 然而,十几年过去了,令人遗憾的是,这种对老子思想的刻板化和标签化的误解似乎依然存在于某些教育体系中。前几天与女儿讨论古代史,她口中重述的,依然是老子思想“消极”的论调。 我深感,历史课本在这种误解的传播中,“功不可没”。 “无为”的真谛:非“躺平”,而是“有所不为” “无为”的本意,绝非我们现在常说的“躺平”或“不作为”。 我认为,这里的“为”的真正内涵,应该是“妄为”或“刻意而为”,即: 违反自然规律; 勉强行事; 出于私心或主观意愿的强行干预。 “无为”不是不行动,而是“无不当为”。它体现在行动上,就是“有所为,有所不为”。只做自己能做的、该做的,不强求能力范围之外的事,不进行过度焦虑或私欲驱动下的强行干预。 这种“妄为”在当今的教育领域尤其明显,“鸡娃”现象便是典型。父母过度焦虑,强行推动孩子做超出其年龄和兴趣范围的事情,便是典型的“刻意而为”与“强行干预”。 “无为”的智慧,在于顺应自然,尽己所能。 当你顺其自然地、尽心尽力地去努力,在各个方面都做到位了,不执着、不强求,最终自然而然会达到“无不为”的境界。这才是“无为而无不为”的真正含义——以不妄为的态度,最终成就一切该成就的事业。 老子的思想,远不是简单的“消极”二字可以概括的,它蕴含着深邃的治理智慧和人生哲理,值得我们每一个人重新去审视和体悟。
陈仓颉
入驻第1年
路人
目视前方,脚踏实地,步履轻快稳定,随时注意来自四方的信息。 以上事情很难做到吗?我觉得对于大多数人而言挺难。至 […]
阿川
入驻第1年
首次徒步爬山,误闯深山老林,徒手爬悬崖,两度滑落险些丧命
姓王者
入驻第1年
再也不见Windows10
前言十年陪伴,终有一别。Windows 10 will reach end of support on October 14, 20252025年10月14日,太平洋时区(PT)(UTC-8)时起,正式停止 Windows 10 的更新与维护对应的北...
老刘
入驻第1年
给Hugo PaperMod主题添加一个漂亮又简洁的友情链接页面
PaperMod 默认是极简风格,没有自带“友情链接(Friends / Links)”页,但是我们博主也不是互联网的孤岛,总有一些自己喜欢的左邻右舍,最简单的方法是用生成一个页面来作为友情链接页面,但是太丑了。老刘结合chatgpt,自己添加一个漂亮的友情链接页面,下面是 详细教程(以 Hugo + PaperMod 为例): 一、创建友情链接页面 在你的 Hugo 项目根目录执行: hugo new friends/_index.md 这会在 content/friends/_index.md 生成文件。 打开该文件,修改为: --- title: "友情链接" layout: "friends" summary: "那些值得一去的好地方" --- ( 注意: layout 是我们下一步要创建的模板文件名。) 二、创建页面模板 PaperMod 的页面模板位于: themes/PaperMod/layouts/ 但我们不直接改主题文件(避免主题升级覆盖),而是复制到你的项目中: mkdir -p layouts/_default 然后创建一个新模板文件: nano layouts/_default/friends.html 写入以下示例模板(简洁、与 PaperMod 风格一致): {{ define "main" }} <main class="main-content" id="main-content"> <article class="post-single"> <header class="post-header"> <h1 class="post-title">{{ .Title }}</h1> {{ with .Params.summary }} <p class="post-description">{{ . }}</p> {{ end }} </header> <style> .friend-links { display: grid; grid-template-columns: repeat(auto-fill, minmax(280px, 1fr)); gap: 1.2rem; margin-top: 1.5rem; } .friend-card { display: flex; align-items: center; padding: 1rem; border-radius: 0.75rem; background: var(--entry); box-shadow: 0 1px 3px rgba(0,0,0,0.1); transition: all 0.25s ease; } .friend-card:hover { transform: translateY(-4px); box-shadow: 0 4px 10px rgba(0,0,0,0.15); } .friend-card img { width: 3rem; height: 3rem; border-radius: 9999px; margin-right: 1rem; } .friend-card .text-gray-600 { color: var(--secondary); } </style> <div class="post-content"> {{ .Content }} <div class="friend-links grid grid-cols-1 sm:grid-cols-2 md:grid-cols-3 gap-4 mt-6"> {{ range .Site.Data.friends }} <a href="{{ .url }}" target="_blank" rel="noopener" class="friend-card flex items-center p-4 rounded-xl shadow-sm hover:shadow-md transition"> <img src="{{ .avatar }}" alt="{{ .name }}" class="w-12 h-12 rounded-full mr-4"> <div> <div class="font-semibold">{{ .name }}</div> <div class="text-sm text-gray-600">{{ .desc }}</div> </div> </a> {{ end }} </div> </div> </article> </main> {{ end }} 三、创建数据文件(友情链接信息) 在项目根目录新建:
JN
入驻第1年
最適合新手的 DJ controller(以及我的收服全過程、使用心得)
我從入門 DJ 以來,一直都是用場地的 CDJ 在演出。但我已經考慮購入 DJ 設備好一陣子了,目的是除了能自己練習以外,還因為有些活動是沒有提供器材的,需要自己準備。考量到價格、體積、搬運之類的因素,我覺得 DJ controller 可能是比較適合我的選擇。 所以,這篇文章就要來聊聊我怎麼選擇要買什麼設備、怎麼買到我的第一台 DJ controller、還有到手之後玩耍的心得如何 XD 我的 DJ 背景 在列出我的需求之前,我想先敘述一下我的 DJ 背景: 我入門 DJ 這件事情,是在 The Wall 工作的時候用 DJM-900 + CDJ-2000NXS * 2 學的,所以自然而然接受了 Pioneer + Rekordbox 的生態系。 我有幾次演出的經驗,全部都是用 DJM + CDJ 完成的,音樂則是從 USB 隨身碟讀取。 使用的方式以接歌為主(EDM + 廣義流行音樂),不會 scratch。 除了 Mixxx,我沒有用過 Serato、Traktor 等其他 DJ 軟體,也暫時沒有想要嘗試。 因為 Rekordbox 並不開源、也不支援 Linux,我也不想被專有軟體綁架,所以我想挑一個支援 Linux + Mixxx 的 controller。 關於 Rekordbox 雖然我說我不想被 Rekordbox 綁架,但這不意味我會直接放棄不用,畢竟如果要用場地的 CDJ 的話,我還是會需要用它來輸出曲庫到 USB 隨身碟。 另外,Pioneer 比較新的 controller 都可以硬體解鎖 Rekordbox 的演出模式,除此之外大部分的基本功能都還是免費。雖然 Pioneer 也在 Rekordbox 加了不少訂閱制的進階功能,但 Pioneer 主要還是在做專業的 DJ 設備,無法免費使用編輯和輸出模式的話,勢必會影響到他們的市佔率,所以我猜測這些免費功能應該不會輕易被拔掉,就先且用且觀察吧 :P 再退一步,Rekordbox 的曲庫可以輸出,Mixxx 也可以讀取。既然退路都確保沒問題了,那就暫時不用太擔心了! 我的需求 有了以上的背景之後,就可以大致列出我的需求了: 相容 Mixxx:因為我不想被專有軟體綁架 可解鎖 Rekordbox:Optional,如果 controller + Mixxx 可以滿足我的需求的話,就不一定需要 內建音效界面:用電腦的雙聲道拆成 2 個單聲道當作 output + 耳機的這個做法我覺得實在太蠢了,我也沒有 4 out 以上的音效界面,而且輸出線都接在 controller 上也比較直覺 選曲按鈕:都用 controller 了還要一直操控電腦我也覺得很蠢,除了一些比較複雜的操作,不然選曲這種非常簡單的事情我還是希望能夠在 controller 上完成 Trim(Gain)旋鈕:同上,而且每首歌的音量都不太一樣,Trim 超級重要啊! 中古品:對我來說東西能用最重要,外殼有點損傷反而省錢也不用擔心碰傷!當然如果一樣價格可以買到新品的話也沒問題 預算: NTD $8000 左右 選手們 列完需求之後,就可以來比較一下選手們了! 考慮到流通性,我就只考慮 Pioneer 跟 Numark 兩個品牌的 controller 了。Pioneer 市占最大不必多說;Numark 則是因為全新品有還算方便的購入管道,而且和 Mixxx 的相容性普遍良好。 DDJ-SB2 優點:根據論壇回饋和 Mixxx 相容性不錯、二手價格不錯 缺點:cue & play 等等重要按鍵和其他功能鍵共用、無法解鎖 Rekordbox 演出模式 DDJ-SB3 優點:相較 SB2 把一些重要的按鍵獨立出來了 缺點:和 Mixxx 的相容性稍差、價格卻又更貴 DDJ-200 優點:應該是 Pioneer 最便宜的 controller,輕巧方便攜帶,大約 4000 就能收到一台二手 缺點:沒有聲音輸出、Trim 旋鈕,這兩大硬傷讓它更像是玩具而不是一個專業設備 DDJ-400 優點:可以滿足我的所有需求、也能硬體解鎖 Rekordbox 的演出模式 缺點:比起其他選擇來說價格偏高 DDJ-FLX2 優點:有一些很酷很潮的新功能、有音效界面、小巧好攜帶 缺點:那些新功能都需要搭配 Rekordbox 使用、而且還是沒有選曲旋鈕 DDJ-FLX4 優點:跟 FLX2 一樣有很多炫炮功能、可以滿足我的所有需求、全新品很容易買到 缺點:真的頗貴、和 Mixxx 的相容性還在慢慢補上 Numark Mixtrack Pro FX 優點:基本滿足我的需求、有比較大的轉盤 & 速度滑杆、全新品不用 8000 就能入手、根據論壇的回饋在 Mixxx 使用沒什麼問題 缺點:操作邏輯和習慣的 Pioneer 產品不太一樣、也不能在 Rekordbox 用,需要確保在 Mixxx 使用沒有問題 Numark Mixtrack Platinum FX 優點:同上,還多了轉盤中間的螢幕 缺點:同上,在 Mixxx 使用有少許問題,而且更貴一些 我收服 controller 的過程 DJ Controller 這種東西在台灣的流通量並沒有非常大,公開二手市場大概只能透過 FB、旋轉拍賣之類的一般的網路二手交易平台,約面交對我來說有點麻煩。 剛好 9 月底我去了日本東京一趟,有去秋葉原就順便去了 HARD OFF 看了一圈,結果就在 1 號店發現了一台 DDJ-400,35000 日羊不含稅!折合台幣是 7000 出頭。 雖然不能測試,但我蠻相信日本的店敢賣這個東西代表有經過最基本的測試;而且這個價格實在是漂亮,在台灣這個價格可能要蹲好一陣子才有可能拿到。算了一下行李還有扣打之後,就毫不猶豫直接帶走了! 因為這台 DDJ-400 沒有盒書只有本體,本來還在擔心要怎麼帶回去飯店,沒想到店員桑還幫忙用泡泡紙包得好好的,真的是非常貼心! 測試 試完之後的結果是:非常幸運,一切都沒問題!只有一些不太明顯的小傷和正常的使用痕跡。 只不過我沒發現 DDJ-400 的耳機輸出是 3.5 mm 的,雖然我的鐵三角 M50x 可以把 6.3 mm 的轉接頭拆下來,不影響使用,但我是覺得有一點麻煩啦… Rekordbox vs Mixxx 因為 Mixxx 和 DDJ-400 的相容性也蠻好的,所以我拿到手之後也有在 Mixxx 上稍微試用看看! Mixxx 搭配 DDJ-400 確實使用上是沒有什麼大問題,但我覺得有幾個小問題還需要克服: 內建的 Reverb 不管我怎麼調都不太好聽,不像 Rekordbox 的有散成一片的感覺 FX 的操作邏輯和 Rekordbox 的不太一樣,所以 DDJ-400 按鈕上面寫的字跟功能會對不起來 雖然可以匯入 Rekordbox 的 memory cue,但會直接轉成 hot cue 雖然可以讀到從 Rekordbox 匯入的 hot cue,但好像還不支援 loop hot cue 雖然 Mixxx 還有這些小問題,但我覺得都不是什麼會嚴重影響使用的問題,甚至有一些問題應該是花點時間客制化一下、或是等新的 feature 發佈就可以解決的,所以 Mixxx 目前對我來說已經是完全可用的軟體! 結語 這次收服 controller 的結果我還蠻滿意的!用了不錯的價格買到了二手的 DDJ-400,也沒有任何故障;搭配 Mixxx 也沒有太大的問題。除了 3.5mm 的耳機孔有點不方便以外,其他都完美符合我的需求! 希望能有越來越多演出可以帶著它上戰場~ 當然如果有活動需要 DJ 的話也歡迎和我聯絡啦

© 2026 好站网HaoZhan.wang 1.5 版权所有

苏ICP备19065220号-4 萌ICP备20269980号 茶ICP备2026050346号 本站数据 版本历史 关于本站