隐私保护

1. 模块演进目标与设计原则 传统“星座运势”类应用常陷入“算命陷阱”：用户打开App → 输入生日 → 获取一段静态文本 → 关闭。这种单次、无状态、低参与的交互，既无法沉淀用户价值，也难以支撑长期产品迭代。我们的演进目标很明确：不止于算命，而在于构建可生长的「灵性体验智能体」——以用户为中心，将星座、塔罗等符号系统转化为动态理解用户的语义接口。 为此，我们确立三大刚性设计原则： ✅ 可扩展性：新占卜体系（如北欧符文、印度Jyotish）应能在不重启服务、不修改核心逻辑的前提下，通过配置+插件方式接入； ✅ 隐私合规：默认遵循GDPR与《个人信息保护法》，所有PII字段强制加密，数据采集遵循“最小必要+显式授权”双基线； ✅ 低耦合：星座偏好、塔罗行为、解读风格等维度必须物理隔离，禁止跨模块直接读库或共享内存。 架构对比一目了然： 基础版（v1.0）：单体后端直连MySQL，/api/v1/horoscope?sign=libra&date=today 返回JSON文本，无用户上下文； 增强版（v2.0）：前端调用统一网关 /api/v2/reading?context=career → 网关路由至 insight-service → 并行调用 astro-service + tarot-service + user-profile-service → 融合生成个性化解读。 演进路线图清晰分阶段： v1.0（已上线）：支持单次占卜、基础埋点、本地用户存储； v1.5（Q3交付）：上线用户画像服务、Flink实时特征管道、OpenID Connect鉴权； v2.0（Q4 GA）：完成微服务拆分、混合推荐引擎上线、GDPR自动化擦除接口就绪。 ⚠️ 注意事项：OpenID Connect 必须启用 prompt=consent 强制二次确认；所有敏感操作（如生日录入）需单独弹窗声明用途，并提供“跳过”选项；配置中心（如Nacos）统一管理星座标签、塔罗牌组映射表，严禁硬编码。 2. 用户画像数据模型设计（含代码示例） 用户画像不是“打标签”，而是构建可计算的行为语义空间。我们定义三个核心实体： UserProfile：用户主干身份（不可变ID + 可变特征快照）； BehaviorLog：原子事件流（抽牌、停留、分享、跳过），带毫秒级时间戳与会话ID； TraitVector：从行为聚合出的向量化特征（如“直觉型解读倾向得分”），供推荐引擎消费。 以下是生产级 Pydantic v2 模型（支持动态字段扩展与校验）： from pydantic import BaseModel, Field, validator from typing import Literal, Optional, Dict, Any from datetime import datetime class UserTrait(BaseModel): astro_sign: Optional[Literal[ "aries", "taurus", "gemini", "cancer", "leo", "virgo", "libra", "scorpio", "sagittarius", "capricorn", "aquarius", "pisces" ]] = None tarot_engagement_score: float = Field(ge=0, le=100, description="0-100加权分，基于点击/收藏/分享/停留时长") interpretive_style: Literal["intuitive", "analytical", "narrative"] = "intuitive" @validator('astro_sign', always=True) def default_unknown(cls, v): return v or "unknown" class UserProfile(BaseModel): user_id: str = Field(..., min_length=12, max_length=32, regex=r'^[a-zA-Z0-9_]+$') traits: UserTrait updated_at: datetime # 敏感字段不在此处定义！生日、手机号等走独立加密存储通道 双数据库实现策略： ...

一、前置知识与环境准备 命理推演的本质是时间坐标的精密转换与关系建模，而非玄学黑箱。本方案严格遵循《渊海子平》《滴天髓》等经典框架，将八字四柱（年、月、日、时）视为一个可计算的时空坐标系——输入是用户提供的公历出生时间与地理经度（如 "1992-02-05 14:30:00", "116.4"），输出是结构化命理数据：四柱干支、十神关系、五行旺衰分值、先天八卦映射编号。整个流程完全离线运行，不依赖任何网络API，既保障用户隐私（出生信息永不离开本地），也支持无网环境下的学术复现与教学演示。 ⚠️ 关键边界声明： 输入：datetime 对象（已带 pytz 时区） + 精确到0.1°的东经度数（如北京116.4°E，上海121.5°E） 输出：JSON 可序列化字典，含 {'year': '壬申', 'month': '壬寅', 'day': '戊辰', 'hour': '己未', 'ten_gods': [...], 'element_strength': {'wood': 0.82, ...}, 'bagua_number': 6} 必需依赖与环境配置 我们禁用所有网络请求类库（如 requests, httpx），仅选用轻量、确定性高的科学计算基础包： # 推荐 Python 版本：3.9+（兼容 `zoneinfo` 且避免旧版 `pytz` 时区陷阱） python3.9 -m venv bazi-env source bazi-env/bin/activate # Linux/macOS # bazi-env\Scripts\activate # Windows pip install julian pytz numpy julian：提供高精度儒略日（JD）计算，误差 < 0.001秒，是节气时刻推算的基石 pytz：处理中国标准时间（CST, Asia/Shanghai）与真太阳时转换 numpy：用于五行旺衰的向量化加权计算（后续章节详述） 时区与真太阳时校正：为什么经度不可省略？ 中国全境统一使用 Asia/Shanghai（UTC+8），但真太阳时（True Solar Time）取决于实际地理经度。北京时间以东经120°为基准，每偏离1°，时间差约4分钟。例如： ...

一、为什么“生辰与命理数据”必须用Keychain而非UserDefaults或普通文件？ 在命理类App中，用户输入的「出生时间（Date）」和「出生地点（String）」看似普通，实则构成生物识别级敏感信息链：精确到分钟的出生时间 + 城市级地点 → 可反推经纬度（误差≤1km）、本地时区、真太阳时（影响八字排盘精度），甚至结合公开气象数据库推算出生时刻光照/地磁参数。这已远超《个人信息保护法》第二十八条定义的“敏感个人信息”范畴——它具备强唯一性、不可变更性与高度可识别性。 而明文存储风险触目惊心： UserDefaults 和 plist 文件以明文形式存于沙盒 Library/Preferences/，越狱设备可通过 iMazing 或 Apple Configurator 2 直接导出全部键值； 沙盒内普通 .json 文件在备份时（iTunes/iCloud）被完整打包，若用户启用“未加密本地备份”，攻击者仅需访问其Mac电脑即可读取所有命理数据； CoreData 默认 SQLite 数据库不启用加密（即使勾选“Use Core Data for storage”，其 .sqlite 文件仍为明文）。我们曾复现某款八字App泄露事件：攻击者通过越狱iPhone提取沙盒，用 DB Browser for SQLite 打开 PersistentStore.sqlite，直接看到 birth_year INTEGER, birth_city TEXT 等明文字段，批量导出超2.3万用户生辰数据并在暗网出售。 Apple官方文档明确指出：“Keychain Services provides a secure container for storing small pieces of sensitive data, such as passwords and cryptographic keys. Items stored in the keychain are encrypted by the system and protected with the user’s device passcode.”（Keychain Services Programming Guide）——其核心是系统级加密隔离：Keychain条目由Secure Enclave协同加密，即使设备被越狱且获得root权限，也无法解密其他应用的Keychain数据。 ...