简介这是一款面向紫微斗数研习者的PC端排盘工具免费免注册、无需安装适用于简体/正体中文系统兼顾入门体验与深度研究命理学爱好者和研究者都能快速上手。软件提供三合盘、飞星盘、四化盘三种排盘风格以及太阴天地人三盘、冬至盘、节气天地人三盘立春盘等多套起盘方法输入方式支持阳历、阴历、四柱可勾选真太阳时并自动匹配系统语言适合公元1000年后的命盘推演。星曜庙旺、四化规则及是否启用均能自定义配合强大查询功能与无限命例保存方便研究者按流派展开分类探讨与回溯校验。资源包共160个文件压缩后仅1.42MB体积虽小但功能完整exe主程序负责排盘运算chm帮助手册便于查阅规则rtf文档用于说明与案例xml配置支持自定义星曜mdb数据库保存命例离线使用与数据管理都较顺手。已有5785人浏览学习适合需要系统收藏命例并进行深入排盘校验的紫微斗数爱好者。1. 易排盘.紫微斗数 V3.0 到底在解决什么问题做紫微斗数排盘软件第一件让人头疼的事不是星曜记不住而是排盘流程里每一步都藏着“人为约定”。同一个生辰有人按晚子时切日有人不切闰二月有人按下月排有人按下半月排。手工排盘还能靠师傅的个人口径兜底写成软件就得把这些约定全部摊开、变成代码里的分支。易排盘.紫微斗数 V3.0 这套软件本质上是把“农历转换 → 安星 → 定四化 → 起大限 → 推流年”这条完整链路做成可复现、可校验的程序让一张盘从输入生辰到输出十二宫不再依赖人肉查表和手指头数格子。它适合两类人。一类是自己排盘排到怀疑人生的命理爱好者另一类是打算把斗数排盘能力集成进自己产品里的开发者。前者需要的是“我按这个软件排出来敢拿去跟书上的例子对”后者需要的是“接口清晰、参数可控、口径可切换”。V3.0 的功能强大如果只体现在堆星曜齐全、界面花哨那就没什么可讲的真正值钱的是它把过去黑匣子一样的安星过程拆成了你能看懂、能改、能验证的步骤。2. 排盘主流程从公历生日到十二宫星曜链路怎么搭紫微斗数的输入非常简单——出生年、月、日、时外加一个性别。输出却是一整张十二宫盘面命宫、兄弟、夫妻、子女、财帛、疾厄、迁移、仆役、官禄、田宅、福德、父母每宫里坐着十几颗星有的带四化有的带亮度外面还套着大限和流年。这一条链路里最容易被新手忽略的是顺序必须先有农历的年月日时才能定干支先有干支和生日才能定五行局先有五行局才能安紫微星继而推出整张盘的骨架。顺序反了后面全是错的。2.1 公历转农历与干支排盘的第一道闸排盘的第一步不是安星而是把公历生日换算成农历并推出年干支、月干支、日干支、时干支。很多人在这里直接翻万年历但软件不能靠人眼查表。常见做法是维护一张 1900 年到 2100 年的农历数据表表中每个整数按二进制位存放当年每月大小、闰月位置和闰月大小。我用 Python 简写一下这个逻辑# 1900-2100 的农历数据来自公开万年历表 # 每个 32 位整数高位到低位依次记录闰月大小、闰月月份、每月大小 LUNAR_TABLE [ 0x04bd8, 0x04ae0, 0x0a570, 0x054d5, 0x0d260, # ……其余年份按同一规则续写 ] def lunar_year_info(year: int) - dict: 取出某一年的农历信息 raw LUNAR_TABLE[year - 1900] leap_month raw 0xf # 低 4 位闰月月份0 表示无闰月 leap_days (raw 16) 0x1 # 闰月是大月(30天)还是小月(29天) month_days (raw 4) 0x1ff # 中间 9 位12 个月的每月大小 return { leap_month: leap_month, leap_month_days: 30 if leap_days else 29, month_days: [(month_days (11 - i)) 1 29 for i in range(12)], }这段逻辑的关键参数是三个位段月份大小占 9 位、闰月月份占 4 位、闰月大小占 1 位。每次把公历日期折算成“距 1900-01-31 的天数”再逐年减去农历年的天数就能定位到具体的农历年月日。这里最常踩的坑是闰月处理如果没有把闰月单独标记出来公历 5 月对应农历四月还是闰四月完全取决于这张表的位标记。所以表本身必须来自可追溯的万年历数据不能自己拍脑袋填否则差一天后面全盘皆输。得到农历日期后干支还要再单独推。年干支按立春切分月干支按节气切分日干支按 60 甲子循环时干支按日干起五鼠遁。这个切分点非常关键——软件里最常见的“差一年”错误就是拿农历正月初一当年干支而不是拿立春当年干支。2.2 安命宫、身宫与十二宫寅宫起数的口诀怎么变成循环排盘流程里最像算法题的一步就是安命宫。口诀是“寅宫起正月顺数至生月再从生月逆数至生时或顺数至生时流派有别”。我一般这样写成循环# 十二地支顺序从寅开始循环 BRANCHES [寅, 卯, 辰, 巳, 午, 未, 申, 酉, 戌, 亥, 子, 丑] def an_ming_gong(month: int, hour_index: int, direction: str counter) - str: month: 农历月份1-12 hour_index: 时辰索引0 表示子时1 表示丑时依此类推 direction: counter 表示倒数至生时forward 表示顺数至生时 start 0 # 寅宫索引 pos (start month - 1) % 12 # 顺数到生月 if direction counter: pos (pos - hour_index) % 12 # 逆数到生时 else: pos (pos hour_index) % 12 # 顺数到生时 return BRANCHES[pos]这段代码本身不复杂但参数 direction 决定了你跟随哪个流派的口诀。大多数传统派别采用“逆数至生时”也有少部分采用顺数。做软件时最怕的就是这里写死一种用户拿着另一种口决的排盘结果来对怎么对都对不上。我的建议是把这个 direction 暴露成配置项而不是在代码里用注释“约定俗成”。身宫的起法跟命宫相似区别在于“从寅宫起正月顺数至生月再从生月顺数至生时”。所以命宫和身宫在代码层面可以共用一个函数只改方向参数。十二宫的排列则是固定顺序命宫确定后逆时针或按你的流派约定依次排兄弟、夫妻、子女等。这里要特别小心斗数的十二宫在地盘上逆时针排但有些书是顺时针画的软件输出时最好同时标注“逆时针排布”字样避免用户拿纸质盘面来对比时产生误解。2.3 定五行局、起紫微星决定命盘骨架的查表逻辑命宫地支和命宫天干出来后下一步是定五行局。五行局有五种水二局、木三局、金四局、土五局、火六局。它由命宫的天干地支组合查“纳音表”得出这个表在排盘软件里通常是一张静态映射表。五行局除了决定紫微星位置还决定了起大限的岁数基数所以它是一个牵一发动全身的中间变量。五行局纳音起运虚岁基数水二局丙子丁丑涧下水2木三局戊寅己卯城头土纳音为土但局归木三3金四局庚辰辛巳白蜡金4土五局壬午癸未杨柳木纳音为木但局归土五5火六局甲申乙酉泉中水纳音为水但局归火六6这里特别容易绕晕五行局的“五行”跟纳音五行并不总是一致比如戊寅己卯的纳音是城头土却归木三局。所以查表时必须按“命宫干支 → 局名 → 基数”的顺序中间不能自己推导否则就会推出完全错误的局。定完局之后用生日数和局数做一次除法求余推紫微星落在哪个宫。这个步骤在代码里就是一次取模运算但取模方向和余数处理方式在不同古籍里也有微差异。我踩过的坑是直接把生日数除局数忽略“余数逢零按局数算”的约定结果紫微星总是往后错一宫。2.4 大限、流年与四化时间维度的三层循环排完十二宫和主星盘面只是静态的。真正让软件显得“功能强大”的是动态维度大限、小限、流年、流月、流日、流时。大限从命宫起按“阳男阴女顺行阴男阳女逆行”的规则推每个大限的跨度就是五行局的基数2 到 6 年。流年则按农历年份的干支和地支找到对应宫位再用流年干去起流年四化。这些时间维度本质上是同一套逻辑的嵌套生年四化定静态盘大限四化定十年流年四化定当年。代码上我把它们设计成三层循环每一层传入“天干”和“当前宫位”复用同一个四化查表函数。如果一上来就把所有四化混在一个数组里后续不管是 UI 标注还是数据导出都会变得一团糟。这也是 V3.0 这类软件最应该做好的地方——分层清晰每一层都能单独验证。3. 星盘的数据结构十二宫、星曜亮度与四化怎么建模排盘逻辑跑通之后紧接着要面对的是数据怎么存。很多人把一张盘直接存成“命宫里有紫微、天机”“夫妻宫里有天梁”这种扁平结构短期能用一旦要展示大限流年、庙旺平陷、四化标记就非常痛苦。我做这个版本的时候把数据模型拆成了三层宫位层、星曜层、动态标记层。3.1 十二宫的数据模型静态宫位、动态星曜分开存我推荐的模型是“宫位为骨架星曜为挂载点四化和大限为标注”。用 TypeScript 写是这样// 星盘核心类型定义 type Brightness 庙 | 旺 | 平 | 陷; // 亮度等级 interface Star { name: string; // 星曜名如 紫微 isMajor: boolean; // 是否十四主星 brightness: Brightness; hua: 禄 | 权 | 科 | 忌 | null; // 四化标记null 表示无四化 } interface Palace { index: number; // 0~11命宫为 0 name: string; // 命宫、兄弟、夫妻…… stars: Star[]; // 本宫星曜 heavenlyStem: string; // 宫干 earthlyBranch: string; // 宫支 limitSpan?: [number, number]; // 大限起止虚岁如 [15, 24] }这里最关键的设计决策是星曜本身的属性亮度、是否主星和它在某张盘上的动态属性是否被四化放在同一个 Star 对象里。亮度虽然是从星曜表查来的静态值但在输出时要跟着宫位走所以放在实例里比放在全局表里更方便。四化标记不单独建数组而是直接挂在星曜实例上这样前端渲染“紫微化科”时只需要读一个字段不需要跨表 join。有人会问为什么不把亮度做成全局静态表非要存进每张盘里因为亮度在少数流派中存在差异例如某颗星在某个宫的亮度说法不一。把亮度冗余进盘数据虽然多占一点存储但换来的是“这张盘在生成那一刻的完整快照”后续不管你改不改全局表历史盘面都不会被污染。这一点对于做批量排盘和长期归档非常重要。3.2 星曜亮度与四化标记用枚举和分层别用魔法字符串星曜亮度这个字段看起来只是一个字实际上最容易被写乱。有人存“旺”“平”有人存“W”“P”还有人存 0/1/2/3 再配一个注释。这种事在单个文件里还能忍一旦你在 UI 上做筛选、排序、统计就全是坑。# 四化查表输入天干返回该天干的四化星曜列表 # 这里只录了两组作为结构示例完整十天干四化表按你所采用的流派补齐 FOUR_HUA_TABLE { 甲: [(廉贞, 禄), (破军, 权), (武曲, 科), (太阳, 忌)], 乙: [(天机, 禄), (天梁, 权), (紫微, 科), (太阴, 忌)], # 其余八组天干…… } def get_four_hua(stem: str) - dict[str, str]: 返回 {星曜名: 四化} 的映射例如 {廉贞: 禄, 破军: 权} result {} for star_name, hua_type in FOUR_HUA_TABLE.get(stem, []): result[star_name] hua_type return result这段代码的眼点在于四化是“按天干整体查表”而不是按星曜逐个 if。有人图省事写成“if stem 甲 and star 廉贞”十条天干十几次判断看着能跑实际上非常难维护。查表结构的另一个好处是你把生年四化、大限四化、流年四化分别调用 get_four_hua 时返回结构完全一致叠加时只需要给 Star.hua 赋值天然支持分层复用。亮度建议直接用 Python 的 Enum 或 TS 的 enum避免字符串散落。我自己见过一个版本里同时出现“旺”“王”“w”三种写法数据清洗洗了整整一个下午。用枚举以后编译器就能帮你拦住这类低级错误运行时完全不需要担心脏数据。3.3 派系差异的建模把“口诀不同”做进配置而不是写死排盘软件最难缠的不是算法复杂度而是流派差异。同一个时辰有的派别命宫同宫有的差一格四化有的用“飞星”有的用“三合”。V3.0 这类软件如果只支持一家之言用户拿其他派别的书来对盘立刻就会说“不准”。我的做法是把所有有分歧的点收集起来做成一个“派系配置档”// 排盘引擎运行配置 interface EngineConfig { ziHourSplit: byDay | byHour; // 晚子时归当日还是次日 leapMonthRule: nextMonth | halfSplit; // 闰月整体按下月还是分上下半月 useTrueSolarTime: boolean; // 是否用真太阳时校正 longitude: number; // 出生地经度东经为正 mingGongDirection: forward | backward; // 安命宫顺数/逆数 fourHuaVersion: classic | modern; // 四化表的版本差异 }配置档不是摆设它要在 UI 上有对应的开关也要在导出的盘面 JSON 里留痕。也就是说任何人拿到你软件排出的 JSON第一眼就能看到这张盘是在哪种口径下生成的。能做到这一点软件就已经从“黑匣子”变成了一个可复现的工具。否则用户 A 和用户 B 用同一个生辰排出两张不同的盘谁也说服不了谁最后锅全在软件头上。4. 定盘参数子时归属、闰月与真太阳时几个决定成败的口径排盘软件里有一类错误特别隐蔽干支都对了、主星也安了但整张盘跟命主实际情况差之毫厘。这类问题往往不是算法 bug而是“输入口径”没问清楚。用户填一个公历生日背后隐藏着至少三个变量出生钟表时间、出生地经度、以及你的软件对子时和闰月的处理规则。这三个变量不锁定排盘结果就永远是薛定谔的盘。4.1 子时归属晚子时切日还是不切日一天十二时辰子时是 23:00 到次日 01:00。问题来了23:00 出生的人日柱算当天还是算第二天这个在术数里叫“晚子时”归属问题。有的派别认为 23:00 已经是次日日柱要进一天有的派别认为 00:00 才算次日23:00 仍用当日日柱。两种口径对命宫和主星的排布没有任何影响但对日干四化和部分流日盘有直接影响。软件在这件事上绝对不能“二选一然后藏着”。我一般在录入界面加一个下拉“23:00-24:00 出生日柱按当日/次日”默认按用户所选流派设好同时把这个选择写进配置对象。更稳妥的做法是提供“晚子时提示”当用户输入的时间落在 23:00-23:59弹一条确认信息让用户自己决定切不切日。这个交互看似多此一举实际能省掉大量售后沟通。4.2 闰月排盘今年闰二月盘按几月排闰月是排盘软件里最容易引发投诉的点。比如农历闰二月出生有的算法直接按下月三月排有的算法按本月二月排还有的算法分上下半月上半月按本月下半月按下月。三种口径各有理论依据但结果差异很大——命宫位置会差一到两格后面的星曜全跟着变。我在代码里把闰月处理抽象成一个独立函数它接收农历月份和是否闰月返回“实际用于排盘的月份”def resolve_leap_month(month: int, is_leap: bool, rule: str) - int: rule: nextMonth 闰月整体按下月排 halfSplit 上半月按本月下半月按下月 sameMonth 闰月按本月排不区分上下半月 返回实际排盘用的月份 if not is_leap: return month if rule nextMonth: return month 1 if rule sameMonth: return month if rule halfSplit: # 上半月 1-15 按本月16 以后按下月 return month if day 15 else month 1 raise ValueError(f未知闰月规则: {rule})注意上面这个函数里的 day 参数我没有写进签名因为它在实际实现里是从农历日期结构体里取的这里只是为了展示分支逻辑。这个函数有两点值得说一是它把“口径”变成了显式参数而不是散落在各处条件里二是它逼着调用方在排盘之前就要明确知道自己用的是哪条规则。如果不确定用户流派宁可拦住用户问清楚也不要默默二选一。4.3 真太阳时与经度修正要不要剔除时区钟表时间如果你只按用户填写的钟表时间排盘那出生地的经度就成了隐形的误差源。中国幅员辽阔统一使用东八区标准时间但同样是早上 8 点在乌鲁木齐和在上海真太阳时差了一个多小时。紫微斗数排盘对时辰极其敏感一个时辰等于两个小时经度偏差超过 30 度就可能把时辰整个切错。常见做法是按出生地经度与东经 120 度的差值做修正每 15 度对应 1 小时。例如东经 87 度的乌鲁木齐修正量约为 (120 - 87) / 15 2.2 小时也就是当地真太阳时比北京时间晚约 2 小时 12 分。软件应该允许用户输入出生地经度然后显示“修正前时辰”和“修正后时辰”。这里我不建议默认开启真太阳时修正因为有些用户所在流派坚持用钟表时间排盘默认修正反而会破坏他们的习惯。正确的设计是录入经度给出推荐值由用户决定是否启用。4.4 用配置对象收口所有口径差异这一节要把前三个小节串起来。如果你把子时切日、闰月规则、真太阳时都做成独立开关最终用户界面会变成一张让人害怕的复杂表单。我的做法是在 UI 上提供“快速流派预设”提示比如预设一“传统三合派”对应晚子时不切日、闰月按下月、不用真太阳时预设二“现代校正派”对应晚子时切日、闰月分上下半月、用真太阳时。用户选预设后具体参数仍可单独微调。这个预设本身不改变引擎逻辑只是给 EngineConfig 批量赋值。它最大的好处是用户不需要理解每一个术语只要选一个自己信任的流派软件就能在正确口径下工作。同时每张排好的盘在导出 JSON 时都带上完整的配置快照这样将来用户回头质疑“这张盘怎么排的”你能打开历史记录把他的配置原样复现。这个习惯救过我很多次比任何口头解释都有力。5. 排盘调试与避坑为什么你排的盘总是差一格排盘软件的 bug 和普通软件的 bug 有一个本质区别它不会报错。你排出的盘可能永远是一张长得挺像样的星盘但某颗星的位置和权威书上差了那么一格。这种不痛不痒的错误最难发现。我自己在这类项目上翻过不少车下面几条是血泪经验每一条都按“现象 → 原因 → 解决”写清楚。5.1 现象同一生辰紫微星位置总是差一格且全部集中在一类生日上这个现象最典型的情况是命宫天干地支都对五行局也对但紫微星落在相邻宫位。排查后发现原因是“生日数除以局数”的余数处理错误。比如水二局生日逢偶数时余数为 0按口诀应当做“余 0 进一宫”处理但我当时直接用了编程语言的取模结果 0导致紫微星少走一格。解决方式不是在代码里 if 特殊处理而是把口诀里的“余数逢 0 按除数算”变成一个显式的归一化函数再配一组手工排盘的测试用例覆盖余数为 0 的生日。5.2 现象命宫对、身宫对、大限起运数不对这个坑出在大限的“阳男阴女顺行阴男阳女逆行”上。我最早实现时只用性别做顺逆判断忘了“阳男阴女”里的阴阳是指年干不是性别本身。结果同年同月同日同时出生的两个异性大限顺逆完全搞反了。排查时单看一张盘不容易发现必须把“年干阴阳 × 性别”组合的四组用例都跑一遍阳男顺、阳女逆、阴男逆、阴女顺。后来我把这个组合直接写成参数化测试一行数据对应一个用例再也没犯过同样的错。5.3 现象生年四化标了流年四化没有这是分层模型没做好导致的典型问题。早期数据模型里只有一个“四化字段”生年四化一写入流年四化就把它覆盖了。表面上是数据丢失根因是没有区分四化的层级。解决方式就是前面讲过的每一层四化分别计算最终叠加时按“流年 大限 生年”的优先级写入标记同时保留每一层的原始结果。调试时打开日志能看到某颗星生年化忌、流年化禄这种叠加信息而不是只看到一个最终值。5.4 现象同一张盘在不同设备上结果不一致排盘软件的算法应该是确定性的同一个输入在任何设备上输出必须完全一致。早期版本里我直接用了设备本地时区去解析用户输入的公历时间字符串导致在不同时区的手机上同一个“1990-05-06 08:00”被解释成了不同时刻进而影响时辰判断。解决方式是录入时间一律按字符串原样解析不经过本地时区转换只按东八区钟表时间对待再视配置做真太阳时修正。这个改动我把规则写在代码注释的最顶部防止后人“好心”帮你加上时区转换。5.5 用一张“手工盘”做回归基线防止改一处崩一片排盘引擎最难的地方在于牵一发动全身。改一个五行局的查表逻辑可能影响几百张盘。我维护了一个“黄金用例集”里面存了十张不同类型的手工盘闰月盘、晚子时盘、节气边界盘、特殊经度盘、普通阳男盘、普通阴女盘。每次改动引擎就先跑一遍这十张盘比对关键字段。下面这段代码就是跑比对用的def verify_chart(case: dict, engine_result: dict) - list[str]: 将手工盘答案与引擎输出逐宫比对返回差异列表 errors [] for i in range(12): expected_stars [s[name] for s in case[palaces][i][stars]] actual_stars [s[name] for s in engine_result[palaces][i][stars]] if expected_stars ! actual_stars: errors.append(f宫位{i} {case[palaces][i][name]} 星曜不一致) # 大限区间也要比不能只看星曜 if case[palaces][i][limitSpan] ! engine_result[palaces][i][limitSpan]: errors.append(f宫位{i} 大限区间不一致) return errors这个函数看起来很简单但它背后的思想是排盘引擎必须有一组“永不改变”的基准答案。每当你优化代码、重构函数、换一种查表写法跑一遍这个用例集如果全绿你就可以放心提交如果红了你能立刻定位到是哪个宫位、哪颗星、哪个字段出了问题。这个用例集就是你的后悔药。没有它改排盘逻辑就像在雷区里散步你不知道哪一步会踩炸。6. 进阶用法批量排盘与回归用例把“容易算错”变成“可验证”到了这一步单张盘已经能排准了接下来值得做的事是把排盘能力变成批量工具。无论是做命理研究、批量试盘还是给产品做数据迁移你迟早会面对几百上千个生辰需要一次性处理。这时候最容易暴露的问题是手工排偶尔错一格批量排就是成片地错。我常用的做法是写一个批量校验脚本读入一个 CSV 文件每一行是一个生辰和对应的“预期结果 JSON 路径”逐行排盘、逐行比对。校验脚本的核心逻辑有三个部分读入用例、调用排盘引擎、比对输出。引擎接口保持纯函数形态输入生辰加配置输出星盘 JSON不碰任何界面状态。这样做的好处是批量脚本和 UI 用的是同一套代码不会出现“界面上排得对脚本里排得不对”的尴尬。比对时建议不只比对星曜名还要比对亮度、四化、大限区间因为这三个字段是后续做流年推演和运势分析的数据基础任何一个错误都会让下游功能失真。我在自己的维护习惯里有一条铁律凡是发现一个新 bug修复之后立刻把对应的生辰和正确结果加进回归用例集并且永远不删除老用例。这个“只增不改”的用例集现在越滚越大但每次改引擎版本时我都有底气直接跑全量回归。V3.0 能让我放心拿来给身边人排盘靠的不是代码写得有多漂亮而是用例集把最容易栽跟头的地方全部钉死了。如果你也想在这个方向投入我建议第一步不是去追求功能多而是先建立自己的测试基线希望帮到你。本文还有配套的精品资源点击获取