從零開始創建屬於自己的 Composer 庫
Composer 是 PHP 領域最流行的依賴管理工具，它使得管理項目依賴變得輕鬆簡單。然而，除了使用現有的包，我們也可以創建和發佈屬於自己的 Composer 包。 在這篇文章中，我將帶你一步一步完成從零開始創建併發佈一個自己的 Composer 包的流程。 創建項目 在你的工作目錄下創建一個新的文件夾作為你的包： mkdir project cd project 初始化 Composer
蘇琢玉 Blog
Stories
List
訂單號老是撞車？我寫了個通用 PHP ID 生成器
在日常開發裏，我們經常會遇到這種情況： 需要給訂單生成唯一編號； 想給日誌或者資源加個標識； 或者需要一個不會重複的 ID，用作數據庫主鍵。 一開始，我也用過 time() 拼接隨機數、或者 uniqid()。 這些方案在小項目裏夠用，但一旦放到併發稍微高點的業務裏，就會出現各種問題： time() 很容易撞車（同一毫秒可能生成多個）； uniqid() 看上去獨特，其實
判斷邏輯越寫越亂，我乾脆做了個自己的規則引擎
不知道你有沒有這種感覺：一個業務功能看起來很簡單，但判斷條件卻一大堆。 什麼用户狀態、配置項、商品屬性、會員等級…… 一大堆 if / else 交織在一起，越寫越亂，稍微改一個邏輯就要擔心影響其他地方。 我之前就遇到這樣的情況，一開始還能忍，後來乾脆決定：不如自己寫一個簡單的規則引擎，專門用來處理這些組合判斷。 於是就有了這個項目：hejunjie/simple-rule-eng
如何優雅地處理多種電商優惠規則？我用 PHP 封裝了一個 Promotion Engine
做電商項目時，經常要處理各種各樣的優惠活動：滿減、打折、VIP 專屬優惠、第二件特價、階梯優惠…… 這些單獨實現起來都不復雜，但當你把它們放在一起，就變得混亂起來了。 我自己在工作裏寫過不少類似的邏輯，每次做法差不多：if/else、switch、各種判斷混在一起，過幾個月回頭看代碼，根本不想維護。 於是我乾脆寫了一個小庫，封裝了常見的優惠計算邏輯，讓這件事更清晰，也能隨時在別的項目裏
構建一個簡潔優雅的 PHP 參數驗證器 —— php-schema-validator
在日常開發中，參數校驗是繞不過的一道坎。我們常常需要確保用户傳入的數據符合預期格式，比如必填字段、數據類型、最大長度、郵箱格式等等。雖然許多 PHP 框架都內置了驗證器，但在開發輕量服務、非框架項目，或需要在業務中後端進行結構化數據校驗時，我總覺得現有方案不夠靈活、冗餘較多。 於是，我動手寫了一個開箱即用、易擴展、輕量級的參數驗證器：php-schema-validator 為什麼要造這個輪子？
PHP 項目裏，哪些功能讓你一次次「重複造輪子」
寫 PHP 第 7 年了，我發現有些功能簡直像韭菜——項目一換就得重新割一遍。 手機號歸屬地、參數校驗、唯一 ID、地址解析……是不是你也寫過不止一次？ 有些功能不難，但就是麻煩： 做個小商城，要寫個 促銷規則引擎 做個 API，就得來一遍 參數驗證器 做用户註冊登錄，要寫個 TOTP 動態口令 做支付結算，要造個 唯一 ID 生成器 這些功能並不是多複雜的“高大上算法”，但就是又常見
從 Hexo 到 Astro：重構我的個人博客
寫博客這件事，老實説，現在可能不太流行了，流量也未必多，但對我來説，有沒有博客是兩回事。 過去幾年，我一直用 Hexo 搭建和維護我的博客，主題豐富、社區活躍，用得也很開心。 老博客： 不過，隨着我對博客的需求越來越多，我發現 Hexo 在一些定製化操作上有些侷限。於是，我決定嘗試用 Astro 來重構我的博客。 新博客： 關於博客這件事 我其實並不指望有
微信小程序開發全流程：從註冊到上線的完整指南
最近在刷小紅書時，看到不少人在分享自己的微信小程序如何靠廣告月入上萬，甚至更多。 這種説法不能説不真實，只能説肯定不是這麼簡單的事情。畢竟廣告收入的多少，歸根結底還是取決於用户量，不可能隨便做個小程序，就能吸引大量用户來看廣告。 不過，完全説不可能也不太準確，畢竟人活着總得有夢想。而且其實做一個簡單的小程序成本並不高，尤其得益於雲開發。小程序後期沒有域名、服務器等額外的軟成本，所有內容都可以部署在
用裝飾器模式實現多層緩存：讓PHP應用更快更穩
為什麼要做多層緩存？ 想象這樣一個場景：你的PHP應用每次訪問數據庫都要花1秒鐘，用户抱怨頁面加載太慢。這時候你會想到加緩存——但只用一層緩存夠嗎？ 比如： 內存緩存雖然快，但重啓服務數據就沒了 Redis緩存能持久化，但網絡請求也有開銷 文件緩存最可靠，但磁盤讀寫速度有限 多層緩存的思路很簡單： 把最快的緩存放在最前面，就像快遞櫃一樣—— 優先從內存取（速度最快） 內存沒有
MySQL 備份 Shell 腳本：支持遠程同步與阿里雲 OSS 備份
之前我寫過一個臨時的 MySQL 備份腳本，主要是為了應急使用，功能比較簡單。現在有時間了，我重新整理了一下，讓它不僅能自動備份數據庫，還支持遠程服務器同步和上傳到阿里雲 OSS，這樣即使本地備份丟失，數據也不會完全丟失。 現在，這個腳本已經發布到 GitHub，地址在這裏： 👉 GitHub 倉庫 - mysql-backup-shell 這個腳本做了什麼？ 這個腳本的核心功能包括：
我寫了個腳本，統計了我自己寫了多少行代碼（純圖一樂）
為什麼要做這件事？ 老實説，我平時不太在意自己到底寫了多少行代碼。 一方面是因為這東西真沒啥太大參考價值，想刷行數的話，複製粘貼個幾千行都不是事；另一方面也是因為誰都知道：代碼質量和行數沒什麼關係。 但有時候，好奇心就是擋不住。 就像你聽到別人講“十萬小時定律”的時候，會突然想： “哎，那我到底練習了多久？” 我寫代碼已經很多年了，也做了不少項目，大部分都丟在 GitHub 上沒怎麼管過。突
RSA+AES 混合加密不復雜，但落地挺煩，我用 Vue+PHP 封裝成了兩個庫
在項目裏寫接口的時候，我有時候會希望再多一層保護。 雖然 HTTPS 已經能保證傳輸安全，但它解決的更多是「傳輸過程中不被竊聽/篡改」的問題。 而我還想順帶做到幾點： 防止接口被隨便模擬調用 就算數據包被截獲，也看不懂內容 就算有人拿着同一份請求去重放，服務端也能拒絕 這些需求其實挺常見的，但並不複雜，説白了就是一套 RSA+AES 混合加密。 經典的思路 原理本身沒什麼新
作為 PHP 開發者，我第一次用 Go 寫了個桌面應用
我平時是做 PHP 的，工作裏基本上都是在寫 Web 應用。説實話，寫久了難免有點慣性思維：服務器、框架、數據庫、API、瀏覽器。 而這次，我做了點不一樣的東西 —— 一個用 Go 寫的財務管理桌面應用。 很多人可能會覺得奇怪：財務管理、記賬軟件，這不已經爛大街了嗎？隨便一搜一大堆，為什麼還要自己做一個？ 我其實一開始也沒打算做什麼大而全的產品，而是因為一個很小的念頭：我想試試 Go 寫應用
再也不用翻一堆日誌！一鍵部署輕量級錯誤監控系統，幫你統一管理 PHP 報錯
維護多個項目的人，大概都明白那種感覺。 平時一切都很平靜，直到某天，甲方的一句“系統是不是出問題了？” 這時候才發現，問題早就埋在那裏了。 你登錄服務器，開始翻日誌、看 trace，一邊調試一邊回想昨天是不是又改了什麼。問題最終解決了，但那種被動的感覺始終在心裏。 我後來想： 這種被動，其實是可以被解決的。 有沒有可能在客户找上門之前，我就已經知道問題在哪，甚至提前修掉？
一個小項目的記錄：PHP 分賬組件
最近整理了一個自己做的小項目——PHP Trade Splitter ，是一個交易/利潤分賬組件。今天想分享一下，也算是記錄自己的小成果，也順便展示一下技術思路。 為什麼會做這個包 説白了，就是因為工作/項目里老是碰到分賬邏輯： 平台抽成 作者收益 代理或渠道分潤 階梯獎勵 多級遞歸計算 以前都是直接寫死在業務裏，每次改需求都得重構，越改越心累。 於是我想：乾脆抽象出來，做一個通用
收藏版：Phinx 數據庫遷移完全指南
最近在維護老項目時，又一次用到了 Phinx。 這個工具我已經用了很多年，幾乎每個項目都會用上它。它屬於那種平時不常用，但每個項目都離不開 的工具。 問題在於，它用得不頻繁，每次寫遷移腳本時總會忘記某個參數怎麼寫、某個字段該用什麼類型。 這些當然可以去查官方文檔，但 Phinx 的文檔雖然內容齊全，卻總讓我覺得信息分散、查起來不夠順手。 於是，我乾脆花點時間，把自己常用的命令、配置方式
想讓默認頭像不再千篇一律，就順手復刻了一下 GitHub 的思路
在各種平台上，初始註冊的用户通常都會被分配一個默認頭像。 但如果你的平台有互動功能，比如評論、留言、排行榜，一堆一模一樣的默認頭像排在一起就會顯得很單調，甚至有些奇怪。 當然，你也可以讓用户自己去換頭像，但現實是：大多數人根本懶得去換。 於是我就想：能不能讓默認頭像也“有點個性”呢？ 然後我想到了 GitHub。 起因 GitHub 的默認頭像其實挺有意思的。 每個新用户的頭像
在 Astro 博客中優雅使用 51.la 統計數據
作為老牌網站流量統計服務商，51.la 提供每月高達 1000 萬次的免費統計額度，非常適合個人博客或小型網站使用。不過，51.la 默認的統計展示是通過嵌入 JS 文件自動渲染的，這種展示方式對美觀性和自定義性有限，對於追求頁面整潔或者想要自己設計展示風格的博主來説不太方便。 我之所以想自己處理 51.la 的統計，是因為我希望更直觀地看到有多少人訪問我的博客，瞭解訪客的訪問情況，從而改進內容和