fix(mp): 修复小程序角色路由 + 前后端字段对齐 + E2E 测试报告
- 修复 stores/auth.ts 三种登录方式从错误路径提取 roles（resp.roles → resp.user.roles） - 首页添加医护人员自动跳转医生端（useDidShow + isMedicalStaff） - services/auth.ts credentialLogin 返回类型补全 roles 字段 - Web 前端 healthData.ts 字段对齐后端 DTO（indicators→items, content→overall_assessment） - Web 前端 medicationReminders.ts 字段对齐（time_slots→reminder_times） - 小程序 report.ts / reports 页面字段对齐后端（indicators→items, doctor_interpretation→doctor_notes） - 小程序 patient.ts / followup.ts / alert.ts 补全缺失字段 - 后端 stats_handler.rs 权限码修正（health.patient.list→health.dashboard.manage） - 新增 V1 E2E 测试报告和五专家组评审报告
This commit is contained in:
iven
@@ -1,12 +1,8 @@
|
||||
import { api } from './request'
|
||||
|
||||
export interface IndicatorDetail {
|
||||
value: number; unit?: string; reference_min?: number; reference_max?: number; status?: string
|
||||
}
|
||||
|
||||
export interface LabReport {
|
||||
id: string; report_date: string; report_type: string
|
||||
indicators: Record<string, IndicatorDetail>; doctor_interpretation?: string
|
||||
items?: unknown; doctor_notes?: string
|
||||
image_urls?: string[]; version: number
|
||||
}
|
||||
|
||||
|
||||
@@ -287,9 +287,17 @@ function HomeDashboard({ modeClass }: { modeClass: string }) {
|
||||
|
||||
export default function Index() {
|
||||
const user = useAuthStore((s) => s.user);
|
||||
const isMedicalStaff = useAuthStore((s) => s.isMedicalStaff);
|
||||
const mode = useUIStore((s) => s.mode);
|
||||
const modeClass = mode === 'elder' ? 'elder-mode' : '';
|
||||
|
||||
// 医护人员访问患者首页时，自动跳转到医生端
|
||||
useDidShow(() => {
|
||||
if (user && isMedicalStaff()) {
|
||||
Taro.redirectTo({ url: '/pages/pkg-doctor-core/index' });
|
||||
}
|
||||
});
|
||||
|
||||
if (!user) {
|
||||
return <GuestHome modeClass={modeClass} />;
|
||||
}
|
||||
|
||||
@@ -45,14 +45,15 @@ export default function ReportDetail() {
|
||||
usePageData(fetchReport, { throttleMs: 60000 });
|
||||
|
||||
const indicators: IndicatorItem[] = React.useMemo(() => {
|
||||
if (!report?.indicators || typeof report.indicators !== 'object') return [];
|
||||
return Object.entries(report.indicators).map(([name, val]) => ({
|
||||
name,
|
||||
value: val.value,
|
||||
unit: val.unit,
|
||||
reference_min: val.reference_min,
|
||||
reference_max: val.reference_max,
|
||||
status: val.status,
|
||||
if (!report?.items || typeof report.items !== 'object') return [];
|
||||
const items = Array.isArray(report.items) ? report.items : [];
|
||||
return items.map((val: Record<string, unknown>, idx: number) => ({
|
||||
name: (val.name as string) || `指标 ${idx + 1}`,
|
||||
value: val.value as number,
|
||||
unit: val.unit as string,
|
||||
reference_min: (val.reference_low ?? val.reference_min) as number | undefined,
|
||||
reference_max: (val.reference_high ?? val.reference_max) as number | undefined,
|
||||
status: val.is_abnormal ? '异常' : '正常',
|
||||
}));
|
||||
}, [report]);
|
||||
|
||||
@@ -89,10 +90,10 @@ export default function ReportDetail() {
|
||||
<Text className='detail-label'>报告日期</Text>
|
||||
<Text className='detail-value'>{report.report_date}</Text>
|
||||
</View>
|
||||
{report.doctor_interpretation && (
|
||||
{report.doctor_notes && (
|
||||
<View className='detail-row'>
|
||||
<Text className='detail-label'>医生解读</Text>
|
||||
<Text className='detail-value'>{report.doctor_interpretation}</Text>
|
||||
<Text className='detail-value'>{report.doctor_notes}</Text>
|
||||
</View>
|
||||
)}
|
||||
</ContentCard>
|
||||
|
||||
@@ -53,10 +53,10 @@ export default function MyReports() {
|
||||
};
|
||||
|
||||
const formatStatus = (report: LabReport) => {
|
||||
const indicators = report.indicators;
|
||||
if (!indicators || typeof indicators !== 'object') return 'unknown';
|
||||
const vals = Object.values(indicators) as Array<{ status?: string }>;
|
||||
const hasAbnormal = vals.some((v) => v.status === 'high' || v.status === 'low');
|
||||
const items = report.items;
|
||||
if (!items || !Array.isArray(items)) return 'unknown';
|
||||
const vals = items as Array<{ is_abnormal?: boolean }>;
|
||||
const hasAbnormal = vals.some((v) => v.is_abnormal);
|
||||
return hasAbnormal ? 'abnormal' : 'normal';
|
||||
};
|
||||
|
||||
|
||||
@@ -2,13 +2,18 @@ import { api } from './request';
|
||||
|
||||
export interface Alert {
|
||||
id: string;
|
||||
patient_id?: string;
|
||||
rule_id?: string;
|
||||
severity: string;
|
||||
title: string;
|
||||
message?: string;
|
||||
status: string;
|
||||
detail?: Record<string, unknown>;
|
||||
created_at: string;
|
||||
updated_at?: string;
|
||||
acknowledged_at?: string;
|
||||
resolved_at?: string;
|
||||
version?: number;
|
||||
}
|
||||
|
||||
export async function listPatientAlerts(patientId: string, params?: { status?: string; page?: number; page_size?: number }) {
|
||||
|
||||
@@ -28,7 +28,7 @@ export interface PatientInfo {
|
||||
}
|
||||
|
||||
export async function credentialLogin(username: string, password: string, tenantId: string) {
|
||||
return api.post<{ access_token: string; refresh_token: string; expires_in?: number; user: { id: string; username: string; display_name?: string; phone?: string; tenant_id?: string } }>('/auth/login', {
|
||||
return api.post<{ access_token: string; refresh_token: string; expires_in?: number; user: { id: string; username: string; display_name?: string; phone?: string; tenant_id?: string; roles?: Array<{ code: string; name: string }> } }>('/auth/login', {
|
||||
username,
|
||||
password,
|
||||
tenant_id: tenantId,
|
||||
|
||||
@@ -6,8 +6,12 @@ export interface FollowUpTask {
|
||||
patient_name?: string;
|
||||
follow_up_type: string;
|
||||
content_template?: string;
|
||||
assigned_to?: string;
|
||||
assigned_to_name?: string;
|
||||
status: string;
|
||||
planned_date: string;
|
||||
completed_at?: string;
|
||||
notes?: string;
|
||||
version: number;
|
||||
}
|
||||
|
||||
|
||||
@@ -5,9 +5,18 @@ export interface Patient {
|
||||
name: string;
|
||||
gender?: string;
|
||||
birth_date?: string;
|
||||
phone?: string;
|
||||
blood_type?: string;
|
||||
id_number?: string;
|
||||
allergy_history?: string;
|
||||
medical_history_summary?: string;
|
||||
emergency_contact_name?: string;
|
||||
emergency_contact_phone?: string;
|
||||
phone?: string;
|
||||
relation?: string;
|
||||
status?: string;
|
||||
verification_status?: string;
|
||||
source?: string;
|
||||
notes?: string;
|
||||
version: number;
|
||||
}
|
||||
|
||||
|
||||
@@ -12,8 +12,8 @@ export interface LabReport {
|
||||
id: string;
|
||||
report_date: string;
|
||||
report_type: string;
|
||||
indicators: Record<string, IndicatorDetail>;
|
||||
doctor_interpretation?: string;
|
||||
items?: unknown;
|
||||
doctor_notes?: string;
|
||||
image_urls?: string[];
|
||||
version: number;
|
||||
}
|
||||
|
||||
@@ -131,8 +131,9 @@ export const useAuthStore = create<AuthState>((set, get) => ({
|
||||
const resp = await authApi.wechatLogin(code);
|
||||
if (resp.bound && resp.token) {
|
||||
const { access_token, refresh_token, user } = resp.token;
|
||||
const roles = (resp as Record<string, unknown>).roles instanceof Array
|
||||
? ((resp as Record<string, unknown>).roles as Array<Record<string, string>>).map((r) => r.code || r.name || String(r))
|
||||
const userObj = user as Record<string, unknown>;
|
||||
const roles = Array.isArray(userObj?.roles)
|
||||
? (userObj.roles as Array<Record<string, string>>).map((r) => r.code || r.name || String(r))
|
||||
: [];
|
||||
secureSet('access_token', access_token);
|
||||
secureSet('refresh_token', refresh_token);
|
||||
@@ -161,19 +162,19 @@ export const useAuthStore = create<AuthState>((set, get) => ({
|
||||
try {
|
||||
const tenantId = Taro.getStorageSync('tenant_id') || process.env.TARO_APP_DEFAULT_TENANT_ID || '';
|
||||
const resp = await authApi.credentialLogin(username, password, tenantId);
|
||||
const roles = (resp as Record<string, unknown>).roles instanceof Array
|
||||
? ((resp as Record<string, unknown>).roles as Array<Record<string, string>>).map((r) => r.code || r.name || String(r))
|
||||
const user = resp.user as Record<string, unknown>;
|
||||
const roles = Array.isArray(user?.roles)
|
||||
? (user.roles as Array<Record<string, string>>).map((r) => r.code || r.name || String(r))
|
||||
: [];
|
||||
secureSet('access_token', resp.access_token);
|
||||
secureSet('refresh_token', resp.refresh_token);
|
||||
if (resp.expires_in) {
|
||||
secureSet('token_expires_at', String(Date.now() + resp.expires_in * 1000));
|
||||
}
|
||||
const user = resp.user;
|
||||
secureSet('user_data', JSON.stringify(user));
|
||||
secureSet('user_data', JSON.stringify(resp.user));
|
||||
secureSet('user_roles', JSON.stringify(roles));
|
||||
secureSet('tenant_id', user.tenant_id || tenantId);
|
||||
set({ user, roles, loading: false });
|
||||
secureSet('tenant_id', resp.user?.tenant_id || tenantId);
|
||||
set({ user: resp.user, roles, loading: false });
|
||||
clearLoggingOut();
|
||||
return true;
|
||||
} catch {
|
||||
@@ -193,8 +194,9 @@ export const useAuthStore = create<AuthState>((set, get) => ({
|
||||
}
|
||||
const resp = await authApi.wechatBindPhone(openid, encryptedData, iv) as Record<string, unknown>;
|
||||
const tokenData = resp as { access_token: string; refresh_token: string; expires_in?: number; user: AuthState['user'] };
|
||||
const roles = resp.roles instanceof Array
|
||||
? (resp.roles as Array<Record<string, string>>).map((r) => r.code || r.name || String(r))
|
||||
const userObj = tokenData.user as Record<string, unknown>;
|
||||
const roles = Array.isArray(userObj?.roles)
|
||||
? (userObj.roles as Array<Record<string, string>>).map((r) => r.code || r.name || String(r))
|
||||
: [];
|
||||
secureSet('access_token', tokenData.access_token);
|
||||
secureSet('refresh_token', tokenData.refresh_token);
|
||||
|
||||
@@ -40,10 +40,10 @@ export interface LabReport {
|
||||
patient_id: string;
|
||||
report_date: string;
|
||||
report_type: string;
|
||||
indicators?: Record<string, unknown>;
|
||||
items?: unknown;
|
||||
image_urls?: string[];
|
||||
doctor_notes?: string;
|
||||
doctor_interpretation?: string;
|
||||
source?: string;
|
||||
status: string;
|
||||
reviewed_by?: string;
|
||||
reviewed_at?: string;
|
||||
@@ -55,9 +55,9 @@ export interface LabReport {
|
||||
export interface CreateLabReportReq {
|
||||
report_date: string;
|
||||
report_type: string;
|
||||
indicators?: Record<string, unknown>;
|
||||
items?: unknown;
|
||||
image_urls?: string[];
|
||||
doctor_interpretation?: string;
|
||||
doctor_notes?: string;
|
||||
}
|
||||
|
||||
export interface HealthRecord {
|
||||
@@ -65,8 +65,10 @@ export interface HealthRecord {
|
||||
patient_id: string;
|
||||
record_type: string;
|
||||
record_date: string;
|
||||
content?: string;
|
||||
attachment_urls?: string[];
|
||||
overall_assessment?: string;
|
||||
report_file_url?: string;
|
||||
source?: string;
|
||||
notes?: string;
|
||||
created_at: string;
|
||||
updated_at: string;
|
||||
version: number;
|
||||
@@ -75,8 +77,8 @@ export interface HealthRecord {
|
||||
export interface CreateHealthRecordReq {
|
||||
record_type: string;
|
||||
record_date: string;
|
||||
content?: string;
|
||||
attachment_urls?: string[];
|
||||
overall_assessment?: string;
|
||||
report_file_url?: string;
|
||||
}
|
||||
|
||||
export interface DailyMonitoring {
|
||||
|
||||
@@ -9,7 +9,7 @@ export interface MedicationReminder {
|
||||
medication_name: string;
|
||||
dosage?: string;
|
||||
frequency: string;
|
||||
time_slots: string[];
|
||||
reminder_times: unknown;
|
||||
start_date?: string;
|
||||
end_date?: string;
|
||||
is_active: boolean;
|
||||
@@ -24,7 +24,7 @@ export interface CreateMedicationReminderReq {
|
||||
medication_name: string;
|
||||
dosage?: string;
|
||||
frequency?: string;
|
||||
time_slots?: string[];
|
||||
reminder_times?: unknown;
|
||||
start_date?: string;
|
||||
end_date?: string;
|
||||
is_active?: boolean;
|
||||
@@ -35,7 +35,7 @@ export interface UpdateMedicationReminderReq {
|
||||
medication_name?: string;
|
||||
dosage?: string;
|
||||
frequency?: string;
|
||||
time_slots?: string[];
|
||||
reminder_times?: unknown;
|
||||
start_date?: string;
|
||||
end_date?: string;
|
||||
is_active?: boolean;
|
||||
|
||||
@@ -53,7 +53,7 @@ export function HealthRecordsTab({ patientId }: Props) {
|
||||
form.setFieldsValue({
|
||||
record_type: record.record_type,
|
||||
record_date: dayjs(record.record_date),
|
||||
content: record.content,
|
||||
overall_assessment: record.overall_assessment,
|
||||
});
|
||||
setModalOpen(true);
|
||||
};
|
||||
@@ -61,7 +61,7 @@ export function HealthRecordsTab({ patientId }: Props) {
|
||||
const handleSubmit = async (values: {
|
||||
record_type: 'checkup' | 'outpatient' | 'inpatient';
|
||||
record_date: Dayjs;
|
||||
content?: string;
|
||||
overall_assessment?: string;
|
||||
}) => {
|
||||
setSubmitting(true);
|
||||
try {
|
||||
@@ -69,7 +69,7 @@ export function HealthRecordsTab({ patientId }: Props) {
|
||||
await healthDataApi.updateHealthRecord(patientId, editingRecord.id, {
|
||||
record_type: values.record_type,
|
||||
record_date: values.record_date.format('YYYY-MM-DD'),
|
||||
content: values.content,
|
||||
overall_assessment: values.overall_assessment,
|
||||
version: editingRecord.version,
|
||||
});
|
||||
message.success('健康记录更新成功');
|
||||
@@ -77,7 +77,7 @@ export function HealthRecordsTab({ patientId }: Props) {
|
||||
await healthDataApi.createHealthRecord(patientId, {
|
||||
record_type: values.record_type,
|
||||
record_date: values.record_date.format('YYYY-MM-DD'),
|
||||
content: values.content,
|
||||
overall_assessment: values.overall_assessment,
|
||||
});
|
||||
message.success('健康记录添加成功');
|
||||
}
|
||||
@@ -105,7 +105,7 @@ export function HealthRecordsTab({ patientId }: Props) {
|
||||
const columns = useMemo(() => [
|
||||
{ title: '记录类型', dataIndex: 'record_type', key: 'record_type', width: 120, render: (v: string) => <Tag>{RECORD_TYPE_MAP[v] || v}</Tag> },
|
||||
{ title: '记录日期', dataIndex: 'record_date', key: 'record_date', width: 120 },
|
||||
{ title: '内容', dataIndex: 'content', key: 'content', ellipsis: true },
|
||||
{ title: '内容', dataIndex: 'overall_assessment', key: 'overall_assessment', ellipsis: true },
|
||||
{ title: '创建时间', dataIndex: 'created_at', key: 'created_at', width: 170, render: (v: string) => new Date(v).toLocaleString('zh-CN') },
|
||||
{
|
||||
title: '操作',
|
||||
@@ -177,7 +177,7 @@ export function HealthRecordsTab({ patientId }: Props) {
|
||||
<Form.Item name="record_date" label="记录日期" rules={[{ required: true, message: '请选择日期' }]}>
|
||||
<DatePicker style={{ width: '100%' }} />
|
||||
</Form.Item>
|
||||
<Form.Item name="content" label="内容">
|
||||
<Form.Item name="overall_assessment" label="内容">
|
||||
<Input.TextArea rows={4} placeholder="健康记录详细内容" />
|
||||
</Form.Item>
|
||||
</Form>
|
||||
|
||||
@@ -79,7 +79,7 @@ export function LabReportsTab({ patientId }: Props) {
|
||||
form.setFieldsValue({
|
||||
report_date: dayjs(record.report_date),
|
||||
report_type: record.report_type,
|
||||
doctor_interpretation: record.doctor_interpretation,
|
||||
doctor_notes: record.doctor_notes,
|
||||
});
|
||||
setModalOpen(true);
|
||||
};
|
||||
@@ -87,7 +87,7 @@ export function LabReportsTab({ patientId }: Props) {
|
||||
const handleSubmit = async (values: {
|
||||
report_date: Dayjs;
|
||||
report_type: string;
|
||||
doctor_interpretation?: string;
|
||||
doctor_notes?: string;
|
||||
}) => {
|
||||
setSubmitting(true);
|
||||
try {
|
||||
@@ -95,7 +95,7 @@ export function LabReportsTab({ patientId }: Props) {
|
||||
await healthDataApi.updateLabReport(patientId, editingRecord.id, {
|
||||
report_date: values.report_date.format('YYYY-MM-DD'),
|
||||
report_type: values.report_type,
|
||||
doctor_interpretation: values.doctor_interpretation,
|
||||
doctor_notes: values.doctor_notes,
|
||||
version: editingRecord.version,
|
||||
});
|
||||
message.success('化验报告更新成功');
|
||||
@@ -103,7 +103,7 @@ export function LabReportsTab({ patientId }: Props) {
|
||||
await healthDataApi.createLabReport(patientId, {
|
||||
report_date: values.report_date.format('YYYY-MM-DD'),
|
||||
report_type: values.report_type,
|
||||
doctor_interpretation: values.doctor_interpretation,
|
||||
doctor_notes: values.doctor_notes,
|
||||
});
|
||||
message.success('化验报告添加成功');
|
||||
}
|
||||
@@ -164,7 +164,7 @@ export function LabReportsTab({ patientId }: Props) {
|
||||
return m ? <Tag color={m.color}>{m.label}</Tag> : <Tag>{v}</Tag>;
|
||||
},
|
||||
},
|
||||
{ title: '医生解读', dataIndex: 'doctor_interpretation', key: 'doctor_interpretation', ellipsis: true },
|
||||
{ title: '医生解读', dataIndex: 'doctor_notes', key: 'doctor_notes', ellipsis: true },
|
||||
{ title: '创建时间', dataIndex: 'created_at', key: 'created_at', width: 170, render: (v: string) => new Date(v).toLocaleString('zh-CN') },
|
||||
{
|
||||
title: '操作',
|
||||
@@ -248,7 +248,7 @@ export function LabReportsTab({ patientId }: Props) {
|
||||
<Form.Item name="report_type" label="报告类型" rules={[{ required: true, message: '请选择类型' }]}>
|
||||
<Input placeholder="如：血常规、生化全套" />
|
||||
</Form.Item>
|
||||
<Form.Item name="doctor_interpretation" label="医生解读">
|
||||
<Form.Item name="doctor_notes" label="医生解读">
|
||||
<Input.TextArea rows={3} placeholder="检查结果解读备注" />
|
||||
</Form.Item>
|
||||
</Form>
|
||||
@@ -271,9 +271,9 @@ export function LabReportsTab({ patientId }: Props) {
|
||||
<p style={{ marginBottom: 8 }}>
|
||||
<strong>报告日期：</strong>{reviewRecord.report_date}
|
||||
</p>
|
||||
{reviewRecord.doctor_interpretation && (
|
||||
{reviewRecord.doctor_notes && (
|
||||
<p style={{ marginBottom: 8 }}>
|
||||
<strong>医生解读：</strong>{reviewRecord.doctor_interpretation}
|
||||
<strong>医生解读：</strong>{reviewRecord.doctor_notes}
|
||||
</p>
|
||||
)}
|
||||
<div style={{ marginTop: 16 }}>
|
||||
|
||||
@@ -17,7 +17,7 @@ where
|
||||
HealthState: FromRef<S>,
|
||||
S: Clone + Send + Sync + 'static,
|
||||
{
|
||||
require_permission(&ctx, "health.patient.list")?;
|
||||
require_permission(&ctx, "health.dashboard.manage")?;
|
||||
let result = stats_service::get_patient_statistics(&state, ctx.tenant_id).await?;
|
||||
Ok(Json(ApiResponse::ok(result)))
|
||||
}
|
||||
@@ -30,7 +30,7 @@ where
|
||||
HealthState: FromRef<S>,
|
||||
S: Clone + Send + Sync + 'static,
|
||||
{
|
||||
require_permission(&ctx, "health.consultation.list")?;
|
||||
require_permission(&ctx, "health.dashboard.manage")?;
|
||||
let result = stats_service::get_consultation_statistics(&state, ctx.tenant_id).await?;
|
||||
Ok(Json(ApiResponse::ok(result)))
|
||||
}
|
||||
@@ -43,7 +43,7 @@ where
|
||||
HealthState: FromRef<S>,
|
||||
S: Clone + Send + Sync + 'static,
|
||||
{
|
||||
require_permission(&ctx, "health.follow-up.list")?;
|
||||
require_permission(&ctx, "health.dashboard.manage")?;
|
||||
let result = stats_service::get_follow_up_statistics(&state, ctx.tenant_id).await?;
|
||||
Ok(Json(ApiResponse::ok(result)))
|
||||
}
|
||||
@@ -56,7 +56,7 @@ where
|
||||
HealthState: FromRef<S>,
|
||||
S: Clone + Send + Sync + 'static,
|
||||
{
|
||||
require_permission(&ctx, "health.patient.list")?;
|
||||
require_permission(&ctx, "health.dashboard.manage")?;
|
||||
|
||||
let patients = safe_aggregate(
|
||||
stats_service::get_patient_statistics(&state, ctx.tenant_id),
|
||||
@@ -95,7 +95,7 @@ where
|
||||
HealthState: FromRef<S>,
|
||||
S: Clone + Send + Sync + 'static,
|
||||
{
|
||||
require_permission(&ctx, "health.patient.list")?;
|
||||
require_permission(&ctx, "health.dashboard.manage")?;
|
||||
let result = safe_aggregate(
|
||||
stats_service::get_lab_report_statistics(&state, ctx.tenant_id),
|
||||
"化验报告统计",
|
||||
@@ -112,7 +112,7 @@ where
|
||||
HealthState: FromRef<S>,
|
||||
S: Clone + Send + Sync + 'static,
|
||||
{
|
||||
require_permission(&ctx, "health.patient.list")?;
|
||||
require_permission(&ctx, "health.dashboard.manage")?;
|
||||
let result = safe_aggregate(
|
||||
stats_service::get_appointment_statistics(&state, ctx.tenant_id),
|
||||
"预约统计",
|
||||
@@ -129,7 +129,7 @@ where
|
||||
HealthState: FromRef<S>,
|
||||
S: Clone + Send + Sync + 'static,
|
||||
{
|
||||
require_permission(&ctx, "health.patient.list")?;
|
||||
require_permission(&ctx, "health.dashboard.manage")?;
|
||||
let result = safe_aggregate(
|
||||
stats_service::get_vital_signs_report_rate(&state, ctx.tenant_id),
|
||||
"体征上报率统计",
|
||||
@@ -146,7 +146,7 @@ where
|
||||
HealthState: FromRef<S>,
|
||||
S: Clone + Send + Sync + 'static,
|
||||
{
|
||||
require_permission(&ctx, "health.patient.list")?;
|
||||
require_permission(&ctx, "health.dashboard.manage")?;
|
||||
let lab_reports = safe_aggregate(
|
||||
stats_service::get_lab_report_statistics(&state, ctx.tenant_id),
|
||||
"化验报告统计",
|
||||
@@ -181,7 +181,7 @@ where
|
||||
HealthState: FromRef<S>,
|
||||
S: Clone + Send + Sync + 'static,
|
||||
{
|
||||
require_permission(&ctx, "health.patient.list")?;
|
||||
require_permission(&ctx, "health.dashboard.manage")?;
|
||||
let result = stats_service::get_personal_stats(&state, ctx.user_id, ctx.tenant_id).await?;
|
||||
Ok(Json(ApiResponse::ok(result)))
|
||||
}
|
||||
|
||||
408
docs/qa/e2e-test-report-v1-release.md
Normal file
408
docs/qa/e2e-test-report-v1-release.md
Normal file
@@ -0,0 +1,408 @@
|
||||
# HMS V1 测试版本端到端测试报告
|
||||
|
||||
> 日期: 2026-05-17 | 测试环境: Windows 11 本地开发 | 分支: feat/media-library-banner
|
||||
> 测试执行者: Claude Code (自动化 E2E 测试 + 5 专业代理并行)
|
||||
|
||||
---
|
||||
|
||||
## 1. 测试概况
|
||||
|
||||
| 指标 | 值 |
|
||||
|------|-----|
|
||||
| 测试执行时间 | ~15 分钟（5 代理并行） |
|
||||
| 测试覆盖范围 | 后端 API + Web 前端 + 微信小程序 + 安全 + 跨平台一致性 |
|
||||
| 后端 API 端点测试 | **48 个端点**，40 PASS / 8 FAIL（路径修正后全部可达） |
|
||||
| Web 前端路由测试 | **25 个活跃路由**，100% 通过 |
|
||||
| 小程序页面覆盖 | **66 页面**（12 主包 + 54 子包），全部代码审查通过 |
|
||||
| 小程序 API 验证 | **19 个核心端点**，全部通过 |
|
||||
| 安全测试项 | **18 项**，15 PASS / 3 FAIL |
|
||||
| 跨平台一致性 | **20+ 实体 × 3 端**对比，发现 3 CRITICAL + 3 HIGH |
|
||||
| 多角色测试 | **5 角色**（admin/doctor/nurse/operator/viewer） |
|
||||
|
||||
---
|
||||
|
||||
## 2. 后端 API 测试结果
|
||||
|
||||
### 2.1 端点可用性（修正路径后）
|
||||
|
||||
#### 健康模块（36/40 PASS）
|
||||
|
||||
| 端点 | 状态码 | 结果 |
|
||||
|------|--------|------|
|
||||
| GET /health/patients | 200 | PASS |
|
||||
| POST /health/patients | 200 | PASS |
|
||||
| GET /health/patients/{id} | 200 | PASS |
|
||||
| PUT /health/patients/{id} | 200 | PASS |
|
||||
| DELETE /health/patients/{id} | 200 | PASS（需 version 字段） |
|
||||
| GET /health/doctors | 200 | PASS |
|
||||
| GET /health/appointments | 200 | PASS |
|
||||
| GET /health/doctor-schedules | 200 | PASS |
|
||||
| GET /health/consultation-sessions | 200 | PASS |
|
||||
| GET /health/media | 200 | PASS |
|
||||
| GET /health/banners | 200 | PASS |
|
||||
| GET /health/alerts | 200 | PASS |
|
||||
| GET /health/follow-up-tasks | 200 | PASS |
|
||||
| GET /health/follow-up-templates | 200 | PASS |
|
||||
| GET /health/articles | 200 | PASS |
|
||||
| GET /health/patient-tags | 200 | PASS |
|
||||
| GET /health/article-categories | 200 | PASS |
|
||||
| GET /health/article-tags | 200 | PASS |
|
||||
| GET /health/care-plans | 200 | PASS |
|
||||
| GET /health/devices | 200 | PASS |
|
||||
| GET /health/ble-gateways | 200 | PASS |
|
||||
| GET /health/vital-signs/today | 200 | PASS |
|
||||
| GET /health/alert-rules | 200 | PASS |
|
||||
| GET /health/action-inbox/stats | 200 | PASS |
|
||||
| GET /health/action-inbox/my-patients | 200 | PASS |
|
||||
| GET /health/shifts | 200 | PASS |
|
||||
| GET /health/admin/system-health | 200 | PASS |
|
||||
| GET /health/admin/statistics/dashboard | 200 | PASS |
|
||||
| GET /health/admin/statistics/patients | 200 | PASS |
|
||||
| GET /health/admin/modules | 200 | PASS |
|
||||
| GET /health/points/account | 200 | PASS |
|
||||
| GET /health/points/products | 200 | PASS |
|
||||
| GET /health/points/orders | 200 | PASS |
|
||||
| GET /health/points/transactions | 200 | PASS |
|
||||
| GET /health/offline-events | 200 | PASS |
|
||||
| GET /health/handoff-logs | 200 | PASS |
|
||||
| GET /health/critical-alerts | 200 | PASS |
|
||||
| GET /health/vital-signs/daily | 400 | FAIL（需 date 参数，但传了仍 400） |
|
||||
| GET /health/medications | 405 | FAIL（GET 不支持，仅 POST） |
|
||||
| GET /health/medication-reminders | 405 | FAIL（GET 不支持） |
|
||||
|
||||
#### 其他模块（12/12 PASS）
|
||||
|
||||
| 端点 | 状态码 | 结果 |
|
||||
|------|--------|------|
|
||||
| GET /workflow/definitions | 200 | PASS |
|
||||
| GET /workflow/tasks/pending | 200 | PASS |
|
||||
| GET /workflow/tasks/completed | 200 | PASS |
|
||||
| GET /ai/analysis/history | 200 | PASS |
|
||||
| GET /ai/prompts | 200 | PASS |
|
||||
| GET /ai/providers | 200 | PASS |
|
||||
| GET /ai/suggestions | 200 | PASS |
|
||||
| GET /config/menus | 200 | PASS |
|
||||
| GET /config/dictionaries | 200 | PASS |
|
||||
| GET /config/themes | 200 | PASS |
|
||||
| GET /messages | 200 | PASS |
|
||||
| GET /messages/unread-count | 200 | PASS |
|
||||
| GET /audit-logs | 200 | PASS |
|
||||
|
||||
### 2.2 CRUD 全链路测试
|
||||
|
||||
| 步骤 | 操作 | 结果 |
|
||||
|------|------|------|
|
||||
| CREATE | POST 创建患者 | PASS — 返回 id + version=1 |
|
||||
| READ | GET 单条查询 | PASS — name/version 正确 |
|
||||
| UPDATE | PUT 更新患者 | PASS — version 自增为 2 |
|
||||
| OPTLOCK | PUT version=1 冲突 | PASS — 返回"版本冲突"错误 |
|
||||
| DELETE | DELETE + version=1 | PASS — 软删除成功 |
|
||||
| LIST SEARCH | 搜索已删除记录 | PASS — 列表不显示 |
|
||||
| GET BY ID | 查询已删除记录 | PASS — 返回错误 |
|
||||
|
||||
### 2.3 性能基线
|
||||
|
||||
| 端点 | 平均响应时间 | 评价 |
|
||||
|------|-------------|------|
|
||||
| GET /health/patients (10次) | **280ms** | 良好 |
|
||||
| GET /health/doctors (10次) | **278ms** | 良好 |
|
||||
| GET /admin/statistics/dashboard (10次) | **291ms** | 良好 |
|
||||
|
||||
---
|
||||
|
||||
## 3. Web 前端测试结果
|
||||
|
||||
> 由 Chrome DevTools MCP 代理实际浏览器测试
|
||||
|
||||
| 指标 | 结果 |
|
||||
|------|------|
|
||||
| 活跃路由 | 25 个，全部可访问 |
|
||||
| 登录流程 | PASS — admin 登录成功跳转仪表盘 |
|
||||
| 页面加载 | PASS — 所有页面正常渲染 |
|
||||
| Console 错误 | 无 CRITICAL 错误 |
|
||||
| 发现问题 | 4 个 LOW 级别 UI/UX 问题 |
|
||||
|
||||
### 3.1 关键页面测试
|
||||
|
||||
| 页面 | 功能 | 状态 |
|
||||
|------|------|------|
|
||||
| 登录页 | 表单验证 + JWT 认证 | PASS |
|
||||
| 仪表盘 | 统计卡片 + 数据加载 | PASS |
|
||||
| 患者管理 | 列表 + 搜索 + 新建 | PASS |
|
||||
| 医生管理 | 列表 + 详情 | PASS |
|
||||
| 预约管理 | 列表 + 新建预约 | PASS |
|
||||
| 咨询管理 | 会话列表 + 消息 | PASS |
|
||||
| 媒体库 | 文件上传 + 预览 | PASS |
|
||||
| 轮播图管理 | CRUD 操作 | PASS |
|
||||
| 权限管理 | 角色列表 + 权限分配 | PASS |
|
||||
| 用户管理 | 列表 + 编辑 | PASS |
|
||||
|
||||
---
|
||||
|
||||
## 4. 小程序端测试结果
|
||||
|
||||
> 综合评分: **8.5/10 (A-)**
|
||||
|
||||
### 4.1 页面覆盖
|
||||
|
||||
| 包 | 页数 | 状态 |
|
||||
|----|------|------|
|
||||
| 主包（6 TabBar + 6 普通） | 12 | PASS |
|
||||
| pkg-health | 5 | PASS |
|
||||
| pkg-doctor-core | 8 | PASS |
|
||||
| pkg-doctor-clinical | 11 | PASS |
|
||||
| pkg-mall | 3 | PASS |
|
||||
| pkg-profile | 19 | PASS |
|
||||
| ai-report | 2 | PASS |
|
||||
| article | 2 | PASS |
|
||||
| pkg-consultation | 1 | PASS |
|
||||
| **合计** | **66** | **100%** |
|
||||
|
||||
### 4.2 API 契约一致性
|
||||
|
||||
19 个核心 API 端点全部验证通过：
|
||||
- 路径一致: 100%
|
||||
- 方法一致: 100%
|
||||
- 请求/响应字段: 一致（核心端点）
|
||||
- 认证方式: 一致（JWT Bearer token）
|
||||
|
||||
### 4.3 安全检查
|
||||
|
||||
| 检查项 | 结果 |
|
||||
|--------|------|
|
||||
| Token 不硬编码 | PASS |
|
||||
| 401 自动处理 | PASS |
|
||||
| 并发限制 (MAX=8) | PASS |
|
||||
| 登出清理 | PASS |
|
||||
| 输入验证 | PASS |
|
||||
| 多租户隔离 | PASS |
|
||||
|
||||
### 4.4 性能优化
|
||||
|
||||
| 策略 | 实现 |
|
||||
|------|------|
|
||||
| 响应缓存 | 60s TTL + 去重 + 最大 100 条 |
|
||||
| 请求去重 | 相同 GET 合并为一次 |
|
||||
| 加载节流 | usePageData 5-30s |
|
||||
| 图片懒加载 | Image lazyLoad |
|
||||
| 安全定时器 | useSafeTimeout 页面隐藏清理 |
|
||||
|
||||
---
|
||||
|
||||
## 5. 跨平台一致性测试结果
|
||||
|
||||
### 5.1 CRITICAL 问题（3 个）
|
||||
|
||||
| ID | 严重性 | 描述 | 位置 |
|
||||
|----|--------|------|------|
|
||||
| CP-1 | **CRITICAL** | 药物提醒字段名不匹配：Web 用 `time_slots`，后端期望 `reminder_times` | `apps/web/src/api/health/medicationReminders.ts` vs `crates/erp-health/src/dto/medication_reminder_dto.rs` |
|
||||
| CP-2 | **CRITICAL** | 化验报告字段名不匹配：前端用 `indicators`/`doctor_interpretation`，后端用 `items`/`doctor_notes` | `apps/web/src/api/health/healthData.ts` + `apps/miniprogram/src/services/report.ts` vs 后端 DTO |
|
||||
| CP-3 | **CRITICAL** | 健康记录字段名不匹配：Web 用 `content`/`attachment_urls`，后端用 `overall_assessment`/`report_file_url` | `apps/web/src/api/health/healthData.ts` vs 后端 DTO |
|
||||
|
||||
**影响**: 这 3 个问题会导致运行时数据丢失或字段写入失败。
|
||||
|
||||
### 5.2 HIGH 问题（3 个）
|
||||
|
||||
| ID | 严重性 | 描述 |
|
||||
|----|--------|------|
|
||||
| CP-4 | HIGH | 小程序患者 DTO 缺少 9 个后端字段（allergy_history 等） |
|
||||
| CP-5 | HIGH | 小程序随访任务 DTO 缺少 assigned_to 等字段 |
|
||||
| CP-6 | HIGH | 小程序告警 DTO 缺少 patient_id/rule_id/version 等 |
|
||||
|
||||
### 5.3 正面发现
|
||||
|
||||
- 三端 API 路径命名 **100% 一致**
|
||||
- HTTP 方法 **100% 一致**
|
||||
- 分页参数 (page/page_size) **一致**
|
||||
- 认证方式（JWT Bearer token）**一致**
|
||||
|
||||
---
|
||||
|
||||
## 6. 安全测试结果
|
||||
|
||||
### 6.1 认证与授权
|
||||
|
||||
| 测试 | 结果 | 说明 |
|
||||
|------|------|------|
|
||||
| 无 Token 访问 | PASS | 返回 401 |
|
||||
| 无效 Token | PASS | 返回 401 |
|
||||
| 错误密码 | PASS | 返回 401 + "未授权" |
|
||||
| 速率限制 | PASS | 5 次错误后触发 429 |
|
||||
| Token 刷新 | PASS | 401 自动 refresh |
|
||||
|
||||
### 6.2 注入攻击防护
|
||||
|
||||
| 测试 | 结果 | 说明 |
|
||||
|------|------|------|
|
||||
| SQL 注入（搜索字段） | PASS | `OR '1'='1` 返回 0 条，参数化查询生效 |
|
||||
| SQL 注入（排序字段） | PASS | 无效排序不报错 |
|
||||
| XSS（存储型） | PASS | `<script>` 在名称验证时被拒绝 |
|
||||
| 命令注入 | PASS | 无命令执行场景 |
|
||||
|
||||
### 6.3 CORS 配置
|
||||
|
||||
| 测试 | 结果 | 说明 |
|
||||
|------|------|------|
|
||||
| 恶意 Origin | **WARNING** | 返回 `access-control-allow-credentials: true`，未限制 Origin |
|
||||
| FHIR metadata | PASS | 返回 401 要求认证 |
|
||||
|
||||
### 6.4 数据保护
|
||||
|
||||
| 测试 | 结果 | 说明 |
|
||||
|------|------|------|
|
||||
| 无效 UUID | PASS | 返回 400 |
|
||||
| 超大分页 | PASS | 服务端限制 page_size 最大 20 |
|
||||
| 负数页码 | PASS | 返回 400 |
|
||||
| 超长搜索 | PASS | 1000 字符正常处理 |
|
||||
| 软删除 | PASS | deleted_at 设置正确，列表过滤生效 |
|
||||
| 乐观锁 | PASS | version 冲突正确拒绝 |
|
||||
| 错误信息泄露 | **INFO** | JSON 解析错误返回原始错误信息 |
|
||||
|
||||
---
|
||||
|
||||
## 7. 多角色权限测试
|
||||
|
||||
### 7.1 测试账号
|
||||
|
||||
| 角色 | 用户名 | 登录 | Token 长度 |
|
||||
|------|--------|------|-----------|
|
||||
| 管理员 | admin | PASS | 7508 |
|
||||
| 医生 | doctor_test | PASS | 1581 |
|
||||
| 护士 | nurse_test | PASS | 992 |
|
||||
| 运营 | operator_test | PASS | 763 |
|
||||
| 查看者 | testuser01 | FAIL | 0（密码可能不同） |
|
||||
|
||||
### 7.2 医生角色端点
|
||||
|
||||
| 端点 | 状态码 | 预期 | 结果 |
|
||||
|------|--------|------|------|
|
||||
| /health/doctor/dashboard | 200 | 200 | PASS |
|
||||
| /health/patients | 200 | 200 | PASS |
|
||||
| /health/appointments | 200 | 200 | PASS |
|
||||
| /health/consultation-sessions | 200 | 200 | PASS |
|
||||
| /health/admin/statistics/dashboard | 200 | **应 403** | **FAIL** — 权限过宽 |
|
||||
|
||||
### 7.3 护士角色端点
|
||||
|
||||
| 端点 | 状态码 | 预期 | 结果 |
|
||||
|------|--------|------|------|
|
||||
| /health/patients | 200 | 200 | PASS |
|
||||
| /health/follow-up-tasks | 200 | 200 | PASS |
|
||||
| /health/alerts | 200 | 200 | PASS |
|
||||
| /health/admin/statistics/dashboard | 200 | **应 403** | **FAIL** — 权限过宽 |
|
||||
|
||||
---
|
||||
|
||||
## 8. 问题汇总（按严重性排序）
|
||||
|
||||
### CRITICAL (3)
|
||||
|
||||
| ID | 模块 | 描述 | 影响 |
|
||||
|----|------|------|------|
|
||||
| CP-1 | 前后端 | 药物提醒字段名不匹配 (time_slots vs reminder_times) | 药物提醒创建/编辑失败 |
|
||||
| CP-2 | 前后端 | 化验报告字段名不匹配 (indicators/items, doctor_interpretation/doctor_notes) | 化验报告数据丢失 |
|
||||
| CP-3 | 前后端 | 健康记录字段名不匹配 (content/overall_assessment, attachment_urls/report_file_url) | 健康记录数据丢失 |
|
||||
|
||||
### HIGH (4)
|
||||
|
||||
| ID | 模块 | 描述 | 影响 |
|
||||
|----|------|------|------|
|
||||
| SEC-1 | 安全 | CORS 未限制 Origin，`access-control-allow-credentials: true` | 恶意网站可发起跨域请求 |
|
||||
| SEC-2 | 权限 | 医生/护士角色可访问 /admin/statistics/dashboard | 管理端点权限泄漏 |
|
||||
| CP-4 | 小程序 | 患者 DTO 缺少 9 个后端字段 | 数据展示不完整 |
|
||||
| CP-5 | 小程序 | 随访任务 DTO 缺少 assigned_to 等字段 | 随访分配信息丢失 |
|
||||
|
||||
### MEDIUM (3)
|
||||
|
||||
| ID | 模块 | 描述 | 影响 |
|
||||
|----|------|------|------|
|
||||
| CP-6 | 小程序 | 告警 DTO 缺少 patient_id/rule_id/version | 告警管理信息不完整 |
|
||||
| API-1 | 后端 | /health/vital-signs/daily 传 date 参数仍返回 400 | 日体征聚合查询不可用 |
|
||||
| API-2 | 后端 | /health/medications 和 /health/medication-reminders 仅支持 POST | GET 列表端点缺失 |
|
||||
|
||||
### LOW (7)
|
||||
|
||||
| ID | 模块 | 描述 |
|
||||
|----|------|------|
|
||||
| UI-1 | Web | 4 个 LOW 级别 UI/UX 文案问题 |
|
||||
| Q-1 | 小程序 | console.warn 残留在 health.ts:67 |
|
||||
| Q-2 | 小程序 | analytics.ts:84 void e 静默吞错误 |
|
||||
| SEC-3 | 安全 | JSON 解析错误返回原始错误信息（低风险） |
|
||||
| ROLE-1 | 权限 | testuser01（查看者）登录失败，密码可能未同步 |
|
||||
| PERF-1 | 性能 | 所有 API 响应 280-290ms，数据库查询优化空间有限 |
|
||||
| FHIR-1 | FHIR | /fhir/R4/Patient 返回 500（需 OAuth 认证，非 JWT） |
|
||||
|
||||
---
|
||||
|
||||
## 9. 数据库状态
|
||||
|
||||
| 实体 | 记录数 | 备注 |
|
||||
|------|--------|------|
|
||||
| patients | 80 | 含测试数据 |
|
||||
| doctors | 12 | 含重复测试数据 |
|
||||
| appointments | 有数据 | 正常 |
|
||||
| consultation_session | 16 | 正常 |
|
||||
| users | 26 | 含测试用户 |
|
||||
| roles | 有数据 | 含 admin/doctor/nurse/operator/患者 |
|
||||
| 总表数 | 147 | 正常 |
|
||||
|
||||
---
|
||||
|
||||
## 10. 风险评估
|
||||
|
||||
### 高风险（发布前必须修复）
|
||||
|
||||
1. **3 个 CRITICAL 字段不匹配** — 会导致用户操作失败且无明确错误提示
|
||||
2. **CORS 未限制 Origin** — 生产环境安全风险
|
||||
3. **管理端点权限泄漏** — 医生/护士可访问管理统计
|
||||
|
||||
### 中风险（建议修复）
|
||||
|
||||
4. 小程序 DTO 字段缺失 — 影响数据完整性展示
|
||||
5. 部分 API 端点缺失 GET 列表 — 功能不完整
|
||||
|
||||
### 低风险（可延后）
|
||||
|
||||
6. UI 文案优化
|
||||
7. Console 残留清理
|
||||
8. 性能微调
|
||||
|
||||
---
|
||||
|
||||
## 11. 发布建议
|
||||
|
||||
### 阻塞项（必须修复才能发布）
|
||||
|
||||
- [ ] CP-1/CP-2/CP-3: 修复 3 个前后端字段名不匹配
|
||||
- [ ] SEC-1: CORS 配置限制可信 Origin
|
||||
- [ ] SEC-2: 管理端点添加权限校验
|
||||
|
||||
### 建议修复
|
||||
|
||||
- [ ] CP-4/CP-5/CP-6: 补齐小程序 DTO 字段
|
||||
- [ ] API-1: 修复 vital-signs/daily 端点
|
||||
- [ ] ROLE-1: 确认查看者角色测试账号密码
|
||||
|
||||
### 可接受现状
|
||||
|
||||
- [x] 核心 CRUD 全链路正常
|
||||
- [x] 安全防护（SQL注入/XSS/速率限制）全部通过
|
||||
- [x] 软删除 + 乐观锁正常
|
||||
- [x] 多角色权限基本隔离正确
|
||||
- [x] 三端 API 路径 100% 一致
|
||||
- [x] 小程序 66 页面全部可用
|
||||
- [x] Web 25 活跃路由全部可访问
|
||||
- [x] API 响应时间 280ms 良好
|
||||
|
||||
---
|
||||
|
||||
## 12. 总结
|
||||
|
||||
| 维度 | 评分 | 说明 |
|
||||
|------|------|------|
|
||||
| 功能完整性 | **8.5/10** | 核心业务链路畅通，3 个字段不匹配需修复 |
|
||||
| 安全性 | **7.5/10** | 注入防护完善，CORS 配置需收紧 |
|
||||
| 性能 | **8.5/10** | 280ms 平均响应，分页限制合理 |
|
||||
| 跨平台一致性 | **7.0/10** | 路径/方法一致，字段名有 3 处不匹配 |
|
||||
| 用户体验 | **8.0/10** | Web/小程序功能完善，少量文案优化 |
|
||||
| **综合评分** | **7.9/10 (B+)** | 修复 3 个 CRITICAL 后可达发布标准 |
|
||||
396
docs/qa/expert-review-v1-release.md
Normal file
396
docs/qa/expert-review-v1-release.md
Normal file
@@ -0,0 +1,396 @@
|
||||
# HMS V1 发布 — 多领域专家评审报告
|
||||
|
||||
> 日期: 2026-05-17 | 分支: feat/media-library-banner | 评审基准: E2E 测试报告 v1-release
|
||||
> 评审团: 产品专家 / 技术架构专家 / 安全专家 / 测试质量专家 / 设计UX专家
|
||||
|
||||
---
|
||||
|
||||
## 评审摘要
|
||||
|
||||
| 维度 | 评分 | 趋势 | 状态 |
|
||||
|------|------|------|------|
|
||||
| 功能完整性 | 8.5/10 | -- | 核心链路畅通，3 个字段不匹配需立即修复 |
|
||||
| 安全性 | 7.5/10 | 较5月审计提升 | 注入防护完善，CORS + 权限边界需收紧 |
|
||||
| 性能 | 8.5/10 | -- | 280ms 平均响应，满足当前规模 |
|
||||
| 跨平台一致性 | 7.0/10 | 需关注 | 路径/方法 100% 一致，DTO 字段名 3 处不匹配 |
|
||||
| 用户体验 | 8.0/10 | 显著提升 | Web 25 路由 + 小程序 66 页面全覆盖 |
|
||||
| **综合** | **7.9/10 (B+)** | **可发布** | 修复 3 CRITICAL + 2 HIGH 后达到 V1 发布标准 |
|
||||
|
||||
**Go/No-Go 建议: 有条件 Go（详见第 4 节）**
|
||||
|
||||
---
|
||||
|
||||
## 1. 五位专家关键洞察
|
||||
|
||||
### 1.1 产品专家视角
|
||||
|
||||
**洞察 1: 核心用户场景覆盖度满足 V1 预期**
|
||||
|
||||
48 个 API 端点 + 25 个 Web 路由 + 66 个小程序页面的覆盖范围，对于一个体检中心/血透中心的健康管理平台 V1 版本来说已属完整。患者管理、预约排班、咨询管理、随访任务、健康数据这五条核心业务链路全部畅通，能够支撑医护人员的日常工作流程。
|
||||
|
||||
**洞察 2: 3 个 CRITICAL 字段不匹配直接影响用户信任**
|
||||
|
||||
药物提醒（time_slots vs reminder_times）、化验报告（indicators vs items）、健康记录（content vs overall_assessment）的字段名不匹配，虽然不影响列表查看，但会导致用户创建/编辑操作静默失败。这种"看起来能操作但数据写不进去"的问题比完全不可用更危险——它会直接损害用户对系统的信任，且用户难以判断是操作失误还是系统问题。
|
||||
|
||||
**洞察 3: 小程序患者端体验已达到可交付水平**
|
||||
|
||||
66 页面 100% 覆盖、19 API 端点全通过、并发控制（MAX=8）、响应缓存（60s TTL）、安全定时器清理等优化措施表明小程序端已经具备了交付给患者使用的基础条件。积分商城、咨询、预约等患者高频场景的功能完备性值得肯定。
|
||||
|
||||
**洞察 4: 首次使用体验（FTUE）存在盲区**
|
||||
|
||||
测试中未覆盖新用户首次登录的引导流程：新患者建档后如何绑定微信、如何查看首条健康数据、如何完成首次预约。这些"从 0 到 1"的场景是用户留存的生死线，建议在发布后第一周优先收集这部分反馈。
|
||||
|
||||
**洞察 5: 用户反馈收集策略建议**
|
||||
|
||||
- 在小程序"个人中心"页面增加"意见反馈"入口（已有积分体系可激励）
|
||||
- 管理后台增加"帮助中心"浮动按钮，收集医护人员操作困惑
|
||||
- 第一周安排 2-3 名种子用户（1 医生 + 1 护士 + 5 患者）进行任务式测试
|
||||
- 每日查看 `audit_logs` 和 API 400/500 错误日志，定位用户实际遇到的障碍
|
||||
|
||||
---
|
||||
|
||||
### 1.2 技术架构专家视角
|
||||
|
||||
**洞察 1: 字段不匹配是缺乏契约测试的症状而非根因**
|
||||
|
||||
3 个 CRITICAL 问题本质上反映了一个架构短板：前后端之间没有强制性的接口契约层。后端 DTO 使用 Rust 的 `serde` 序列化字段名（snake_case），前端 TypeScript 接口独立定义字段名，两者之间没有自动化的同步校验机制。当前项目有 52 个 API 模块、189 个后端 DTO 文件，纯靠人工维护一致性不可持续——历史数据也证明了这一点（35 次 fix 源于前后端接口不一致）。
|
||||
|
||||
根因分析：
|
||||
- `medicationReminders.ts` 使用 `time_slots` 而后端 DTO 使用 `reminder_times` —— 两端独立命名，无交叉验证
|
||||
- `healthData.ts` 的化验报告接口使用 `indicators` + `doctor_interpretation`，后端实际是 `items` + `doctor_notes` —— 后端 DTO 经历过重构但前端未同步
|
||||
- 健康记录的 `content`/`attachment_urls` vs `overall_assessment`/`report_file_url` —— 同理
|
||||
|
||||
**洞察 2: 建议引入自动化契约检测**
|
||||
|
||||
短期（1 周内可落地）：
|
||||
- 利用后端已有的 utoipa OpenAPI 生成能力，从 `openapi.json` 自动提取所有 DTO schema
|
||||
- 编写脚本对比前端 TypeScript interface 与 OpenAPI schema 的字段名/类型一致性
|
||||
- 集成到 CI pipeline，字段不匹配时构建失败
|
||||
|
||||
中期（1 个月内）：
|
||||
- 引入 `spectral` 或 `optic` 进行 API 契约测试
|
||||
- 前端 API 层考虑从 OpenAPI spec 自动生成 TypeScript 类型（如 `openapi-typescript`）
|
||||
- 建立后端 DTO 变更时的"破坏性变更"自动检测
|
||||
|
||||
**洞察 3: API 版本管理现状评估**
|
||||
|
||||
当前所有端点使用 `/api/v1/` 前缀，这是正确的版本化起点。但需要注意：
|
||||
- 没有 API 版本弃用（deprecation）机制——未来字段变更时如何平滑过渡
|
||||
- FHIR 端点（`/api/v1/fhir/R4/`）使用 OAuth 认证而非 JWT，与主 API 认证体系不一致
|
||||
- 建议：V1 发布后冻结当前 DTO 结构，所有非向后兼容的变更走 v2 路径
|
||||
|
||||
**洞察 4: 权限模型的粒度问题**
|
||||
|
||||
`stats_handler.rs` 中 `get_dashboard_stats` 使用 `health.patient.list` 权限而非专用的管理员权限。这意味着任何有"患者列表"查看权限的角色（医生、护士）都能访问管理统计仪表盘，这是 SEC-2 权限泄漏的根因。正确做法是引入 `health.admin.dashboard` 或 `health.statistics.view` 权限码，并在 seed 迁移中只分配给 admin 角色。
|
||||
|
||||
**洞察 5: 生产环境部署前技术检查清单**
|
||||
|
||||
| 检查项 | 当前状态 | 要求 |
|
||||
|--------|---------|------|
|
||||
| CORS Origin 白名单 | 开发模式 wildcard | 必须配置具体域名（已有 release 模式 panic 保护） |
|
||||
| 数据库连接池 | 默认配置 | 建议根据并发量调整 pool_size |
|
||||
| 日志级别 | tracing warn+ | 生产环境建议 info + 结构化日志输出到文件 |
|
||||
| 健康检查端点 | 未明确 | 建议 `/health` 端点用于负载均衡探测 |
|
||||
| 优雅关闭 | 已实现（main.rs 优雅关闭） | 验证信号处理正确性 |
|
||||
| TLS | 未配置 | 生产环境必须启用 HTTPS |
|
||||
| 备份策略 | 未验证 | 数据库自动备份 + 恢复演练 |
|
||||
|
||||
---
|
||||
|
||||
### 1.3 安全专家视角
|
||||
|
||||
**洞察 1: CORS 配置已有双模式保护，但需确认生产配置**
|
||||
|
||||
代码审查显示 CORS 层已有合理的双模式实现（`build_cors_layer` 函数）：
|
||||
- `debug_assertions`（开发模式）：允许 wildcard，打印警告
|
||||
- `release` 模式：wildcard 时直接 panic 拒绝启动
|
||||
|
||||
测试中观察到 `access-control-allow-credentials: true` 是因为在开发模式下运行。**生产环境只要确保 `ERP__CORS__ALLOWED_ORIGINS` 环境变量设置正确的域名，此问题自动解决。** 但建议：
|
||||
- 在部署文档中明确标注此环境变量为必填项
|
||||
- 添加启动时日志输出当前 CORS 配置，便于排查
|
||||
|
||||
**洞察 2: 管理端点权限泄漏是权限设计缺陷**
|
||||
|
||||
如架构专家所述，`get_dashboard_stats` 使用了 `health.patient.list` 权限而非管理员专属权限。这不是 CORS 或中间件的问题，而是权限码粒度不够。修复方案：
|
||||
- 新增权限码 `health.admin.statistics`
|
||||
- 在 `stats_handler.rs` 中将 `health.patient.list` 替换为 `health.admin.statistics`
|
||||
- 在角色权限 seed 中只将此权限分配给 admin 角色
|
||||
- 同理审查 `get_system_health`、`get_user_activity`、`get_module_status` 等管理端点（这些已使用 `health.dashboard.manage`，但 dashboard_stats 遗漏了）
|
||||
|
||||
**洞察 3: 认证和注入防护已达到生产级水平**
|
||||
|
||||
测试结果表明：
|
||||
- SQL 注入防护：参数化查询生效，`OR '1'='1` 返回 0 条
|
||||
- XSS 防护：`<script>` 标签在验证时被拒绝
|
||||
- 速率限制：5 次错误后触发 429
|
||||
- Token 安全：401 自动 refresh、登出清理
|
||||
- 软删除 + 乐观锁：数据完整性保护到位
|
||||
|
||||
这些是医疗系统最关键的安全基础，当前实现已满足 V1 要求。
|
||||
|
||||
**洞察 4: 数据保护和合规建议**
|
||||
|
||||
- PII 脱敏已实现（身份证 310****0012、电话 138****8000）
|
||||
- AES-256-GCM 加密已用于敏感字段（设计规格已定义）
|
||||
- 建议：发布前确认所有患者身份信息（姓名、身份证、手机号）在 API 响应中均已脱敏
|
||||
- 日志中不应包含患者身份信息（检查 tracing 输出）
|
||||
- 如涉及跨境数据传输，需评估数据本地化要求
|
||||
|
||||
**洞察 5: JSON 解析错误信息泄露（SEC-3）风险评估**
|
||||
|
||||
测试发现 JSON 解析错误返回原始错误信息。这属于低风险，因为：
|
||||
- 仅在请求体格式错误时触发
|
||||
- 不泄露数据库结构或内部路径
|
||||
- 但建议统一错误响应格式，对外只返回"请求格式错误"，详细信息写日志
|
||||
|
||||
---
|
||||
|
||||
### 1.4 测试质量专家视角
|
||||
|
||||
**洞察 1: 测试覆盖范围广但深度不均**
|
||||
|
||||
当前测试覆盖了：
|
||||
- 后端 API: 48 端点（约 18% 的 260+ 路由）
|
||||
- Web 前端: 25 活跃路由 100%（但功能深度仅验证了加载）
|
||||
- 小程序: 66 页面代码审查（UI 自动化仅 19 页面）
|
||||
- 后端单元/集成: 943 个函数
|
||||
|
||||
缺失的关键测试场景：
|
||||
- **端到端业务流程测试**：患者创建 -> 预约 -> 就诊 -> 健康数据录入 -> 告警触发 -> 随访 -> 结案，这条完整链路未被自动化测试覆盖
|
||||
- **并发场景测试**：排班 CAS 操作、积分并发扣减、预约超额防护——这些是系统最脆弱的环节
|
||||
- **小程序真机测试**：当前仅 DevTools 模拟器，真机上的 BLE 设备同步、推送通知等场景未验证
|
||||
- **离线/弱网测试**：小程序在地铁、电梯等弱网环境下的行为未测试
|
||||
|
||||
**洞察 2: 前后端契约测试是最紧迫的测试缺口**
|
||||
|
||||
3 个 CRITICAL 问题都源于缺乏自动化契约验证。建议建立三层防护：
|
||||
1. **静态分析层**：OpenAPI schema vs TypeScript interface 自动对比（CI 集成）
|
||||
2. **集成测试层**：前端 API 模块的 mock 数据与后端实际响应结构对比
|
||||
3. **E2E 测试层**：创建操作的完整 round-trip 验证（创建 -> 查询 -> 验证字段值）
|
||||
|
||||
**洞察 3: 质量门禁建议**
|
||||
|
||||
为防止回归，建议在 CI 中设置以下门禁：
|
||||
- `cargo test --workspace` 全通过（已有）
|
||||
- `pnpm test` 前端测试全通过（已有 472 断言）
|
||||
- API 契约一致性检查（新增）
|
||||
- Clippy 0 警告（已有）
|
||||
- 安全扫描: `cargo audit` + 前端依赖漏洞检查（新增）
|
||||
- 性能基线: 核心端点 P95 < 500ms（新增）
|
||||
|
||||
**洞察 4: 测试数据管理策略**
|
||||
|
||||
当前数据库有 80 患者、26 用户、12 医生的测试数据，但这些数据与生产数据混杂。建议：
|
||||
- 建立专用的 E2E 测试数据种子（可重复创建/销毁）
|
||||
- 测试用例不应依赖特定数据的 ID（使用创建后返回的 ID）
|
||||
- 引入测试数据快照机制，每次 E2E 测试前恢复到已知状态
|
||||
|
||||
**洞察 5: 回归测试策略**
|
||||
|
||||
基于历史 24% fix 率的教训，建议：
|
||||
- **每次发布前**：运行完整 E2E 测试套件（当前 15 分钟）
|
||||
- **每个 PR**：运行后端测试 + 前端测试 + API 契约检查（目标 < 5 分钟）
|
||||
- **每日**：运行全量 E2E + 性能基线 + 安全扫描
|
||||
- **每周**：多角色权限测试（R01-R05 全量回归）
|
||||
- 优先自动化高频 fix 领域的测试：前后端接口一致性、权限码、菜单配置
|
||||
|
||||
---
|
||||
|
||||
### 1.5 设计/UX 专家视角
|
||||
|
||||
**洞察 1: Web 端 UI 问题优先级评估**
|
||||
|
||||
4 个 LOW 级别 UI/UX 问题的影响评估：
|
||||
- **文案类**（如按钮文字、表单标签）：V1 可接受，不影响功能使用。用户首次使用时可能短暂困惑，但上下文足够理解含义。建议在发布后第二周统一优化。
|
||||
- **视觉一致性**：Ant Design 组件库确保了基础的视觉一致性，4 个 LOW 问题更可能是局部的文案不精确或间距微调，不涉及布局或交互设计缺陷。
|
||||
|
||||
**洞察 2: 小程序 66 页面设计一致性评估**
|
||||
|
||||
正面发现：
|
||||
- 统一组件库迁移已完成（75 SCSS 页面使用 CSS 变量主题）
|
||||
- `.doctor-mode` / `.elder-mode` CSS 变量级联覆盖机制已建立
|
||||
- 长者模式 58/58 页面 100% 覆盖
|
||||
|
||||
需关注的点：
|
||||
- 小程序 DTO 缺失字段（CP-4/CP-5/CP-6）会导致部分页面信息展示不完整——用户看到"空"字段比没有该功能更糟糕
|
||||
- 建议：对于 DTO 缺失的字段，前端做优雅降级（显示"暂无数据"而非空白或 undefined）
|
||||
|
||||
**洞察 3: 长者模式和无障碍设计评估**
|
||||
|
||||
长者模式 58/58 页面 100% 覆盖是值得肯定的成绩。评估要点：
|
||||
- 字号 >= 22px 的要求已满足
|
||||
- 建议进一步验证：色彩对比度是否满足 WCAG 2.1 AA 标准（特别是灰色辅助文字）
|
||||
- 触摸目标尺寸是否 >= 44x44px（微信小程序推荐）
|
||||
- 是否有纯靠颜色区分的信息（色盲友好性）
|
||||
- 语音辅助功能（screen reader）的语义化标签使用情况
|
||||
|
||||
**洞察 4: 首次使用体验（FTUE）建议**
|
||||
|
||||
当前系统缺少新用户引导机制，建议在 V1.1 中补充：
|
||||
- **医护端**：首次登录显示 3-5 步快速引导（仪表盘概览、患者管理入口、常用操作位置）
|
||||
- **患者端**：建档完成后显示"下一步建议"（绑定微信、查看健康数据、预约体检）
|
||||
- **空状态设计**：各列表页面的空状态应包含引导文案和操作按钮（"暂无预约记录，点击预约体检"）
|
||||
- **帮助入口**：每个页面增加"?"帮助图标，链接到操作说明
|
||||
|
||||
---
|
||||
|
||||
## 2. 共识建议（所有专家一致同意）
|
||||
|
||||
### 2.1 发布前必须修复（阻塞项）
|
||||
|
||||
| 优先级 | 问题 | 修复工作量估计 | 负责领域 |
|
||||
|--------|------|--------------|----------|
|
||||
| P0 | CP-1/CP-2/CP-3: 前后端字段名对齐 | 2-3 小时 | 前端 |
|
||||
| P0 | SEC-2: 统计端点权限码升级为 `health.admin.statistics` | 1 小时 | 后端 |
|
||||
| P0 | SEC-1: 确认生产 CORS 配置（已有代码保护，仅需配置环境变量） | 30 分钟 | 运维 |
|
||||
|
||||
**修复顺序建议**：先 SEC-2（后端改动小、影响大），再 CP-1/2/3（前端对齐），最后 SEC-1（部署配置）。
|
||||
|
||||
### 2.2 发布后一周内修复
|
||||
|
||||
| 优先级 | 问题 | 说明 |
|
||||
|--------|------|------|
|
||||
| P1 | CP-4/CP-5: 小程序患者/随访 DTO 补齐 9+ 字段 | 影响数据展示完整性 |
|
||||
| P1 | API-1: 修复 vital-signs/daily 端点 400 | 影响体征趋势分析 |
|
||||
| P1 | 建立前后端契约自动化检查 | 防止此类问题再次发生 |
|
||||
|
||||
### 2.3 发布后两周内修复
|
||||
|
||||
| 优先级 | 问题 | 说明 |
|
||||
|--------|------|------|
|
||||
| P2 | CP-6: 小程序告警 DTO 补齐字段 | 告警管理信息完整性 |
|
||||
| P2 | API-2: 补齐 medications/medication-reminders GET 列表端点 | 功能完整性 |
|
||||
| P2 | SEC-3: 统一 JSON 错误响应格式 | 减少信息泄露 |
|
||||
| P2 | ROLE-1: 确认查看者角色测试账号 | 测试基础设施 |
|
||||
| P2 | 小程序 console 残留清理（Q-1/Q-2） | 代码质量 |
|
||||
|
||||
---
|
||||
|
||||
## 3. 分歧点
|
||||
|
||||
### 分歧 1: FHIR 端点 500 是否阻塞发布
|
||||
|
||||
- **安全专家**：建议修复。FHIR 端点返回 500 可能暴露内部错误信息，且 FHIR 是对外标准接口，应保证可用性。
|
||||
- **技术架构专家**：建议不阻塞。FHIR 使用 OAuth 认证体系，与主 API 的 JWT 体系不同，当前 V1 主要面向内部使用场景，FHIR 是对外接口，可在 V1.1 中修复。
|
||||
- **产品专家**：同意不阻塞。V1 目标用户是内部医护人员和患者，不涉及外部系统对接。
|
||||
- **结论**：不阻塞发布，纳入 V1.1 修复计划。
|
||||
|
||||
### 分歧 2: API 响应 280ms 是否需要优化
|
||||
|
||||
- **性能角度**：280ms 对当前规模（80 患者）是合理的，但线性增长后在生产规模（1000+ 患者）可能成为瓶颈。
|
||||
- **产品角度**：用户体感上 280ms 是可接受的（< 300ms 被认为是"即时响应"），优先解决功能问题。
|
||||
- **结论**：不阻塞发布，但建议在 V1.1 中建立性能基线监控，在患者数达到 500 时进行压力测试。
|
||||
|
||||
### 分歧 3: 小程序 DTO 缺失字段是否阻塞发布
|
||||
|
||||
- **UX 专家**：建议至少修复 CP-4（患者 DTO 缺 9 字段），因为患者信息是最高频查看的数据，缺失字段会影响医护人员的临床决策。
|
||||
- **产品专家**：这些字段大多数是"锦上添花"信息（allergy_history、emergency_contact 等），核心的身份信息、诊断信息已完整展示。
|
||||
- **测试专家**：从质量角度看，DTO 缺失字段意味着前端无法展示后端已有的数据，这是数据一致性缺陷，应在发布前修复。
|
||||
- **结论**：CP-4 纳入发布后一周内修复，不阻塞发布。前端对缺失字段做优雅降级处理。
|
||||
|
||||
---
|
||||
|
||||
## 4. Go/No-Go 建议
|
||||
|
||||
### 判定: 有条件 Go
|
||||
|
||||
**条件：**
|
||||
|
||||
1. 修复 3 个 CRITICAL 前后端字段不匹配（CP-1/CP-2/CP-3）—— 预计 2-3 小时
|
||||
2. 修复管理端点权限泄漏（SEC-2）—— 预计 1 小时
|
||||
3. 确认生产环境 CORS 配置正确 —— 预计 30 分钟
|
||||
4. 在生产环境执行一次完整冒烟测试验证修复效果 —— 预计 1 小时
|
||||
|
||||
**总修复时间：约 5-6 小时**
|
||||
|
||||
### Go 的理由
|
||||
|
||||
- 核心业务链路（患者 CRUD、预约管理、咨询管理、健康数据、随访任务）100% 畅通
|
||||
- 安全基础设施（SQL 注入、XSS、速率限制、PII 脱敏、软删除、乐观锁）全部通过
|
||||
- 三端覆盖（Web 25 路由 + 小程序 66 页面 + 48 API 端点）达到 V1 标准
|
||||
- 小程序综合评分 8.5/10
|
||||
- 3 个 CRITICAL 问题修复路径清晰、工作量可控
|
||||
- CORS 问题在生产构建中已有 panic 保护机制
|
||||
|
||||
### No-Go 的触发条件
|
||||
|
||||
- 3 个 CRITICAL 修复过程中发现更深层的数据模型问题
|
||||
- 管理端点权限修复导致其他端点权限被意外收紧
|
||||
- 生产环境部署验证发现数据库迁移冲突
|
||||
- 安全扫描发现新的 HIGH/CRITICAL 级别漏洞
|
||||
|
||||
---
|
||||
|
||||
## 5. 发布后两周迭代计划
|
||||
|
||||
### 第一周（D+1 ~ D+7）：稳定性周
|
||||
|
||||
| 天 | 任务 | 目标 |
|
||||
|----|------|------|
|
||||
| D1 | 部署到生产环境 + 种子用户开通 | 验证生产环境可用性 |
|
||||
| D2 | 监控 API 错误率 + 修复紧急问题 | P0 指标: API 500 率 < 0.1% |
|
||||
| D3 | 修复 CP-4（小程序患者 DTO 补齐） | 数据展示完整性 |
|
||||
| D4 | 修复 CP-5/CP-6（小程序随访/告警 DTO）| 数据展示完整性 |
|
||||
| D5 | 修复 API-1（vital-signs/daily 端点）+ API-2（medications GET） | 功能完整性 |
|
||||
| D6 | 建立前后端契约自动化检查 + 集成到 CI | 防止回归 |
|
||||
| D7 | 种子用户反馈收集 + 第一次迭代计划 | 用户驱动优化 |
|
||||
|
||||
### 第二周（D+8 ~ D+14）：体验优化周
|
||||
|
||||
| 天 | 任务 | 目标 |
|
||||
|----|------|------|
|
||||
| D8 | UI 文案统一优化（UI-1） | 视觉一致性 |
|
||||
| D9 | Console 残留清理 + 代码质量提升 | 工程质量 |
|
||||
| D10 | 空状态设计 + FTUE 引入（医护端） | 首次使用体验 |
|
||||
| D11 | FHIR 端点 500 修复 + OAuth 配置 | 外部集成准备 |
|
||||
| D12 | 性能基线建立 + P95 监控 | 性能可观测性 |
|
||||
| D13 | 小程序真机测试（至少 3 款机型） | 兼容性验证 |
|
||||
| D14 | V1.1 发布准备 + 回归测试 | V1.1 质量保证 |
|
||||
|
||||
### V1.1 发布标准
|
||||
|
||||
- 所有 HIGH 及以上问题已修复
|
||||
- API 契约自动化检查集成到 CI
|
||||
- 种子用户反馈中 CRITICAL/HIGH 问题全部解决
|
||||
- 性能基线: P95 < 500ms
|
||||
- 小程序真机测试至少覆盖 iOS + Android 各 1 款
|
||||
|
||||
---
|
||||
|
||||
## 附录 A: 问题溯源矩阵
|
||||
|
||||
| 问题 ID | 根因分类 | 检出阶段 | 历史频率 | 自动化防护可行性 |
|
||||
|---------|---------|---------|---------|-----------------|
|
||||
| CP-1 | 前后端独立命名 | E2E 测试 | 35 次 fix 史 | 高（OpenAPI 对比） |
|
||||
| CP-2 | 后端重构未同步前端 | E2E 测试 | 同上 | 高 |
|
||||
| CP-3 | 同 CP-2 | E2E 测试 | 同上 | 高 |
|
||||
| SEC-1 | 开发环境默认配置 | 安全测试 | 首次发现 | 中（CI 环境检查） |
|
||||
| SEC-2 | 权限码粒度不足 | 角色测试 | 首次发现 | 中（权限矩阵测试） |
|
||||
| CP-4/5/6 | 小程序 DTO 手动维护 | 跨平台测试 | 常见 | 高（代码生成） |
|
||||
| API-1/2 | 端点设计遗漏 | API 测试 | 偶发 | 低（人工 review） |
|
||||
|
||||
## 附录 B: 代码审查关键文件
|
||||
|
||||
| 文件 | 问题 | 建议操作 |
|
||||
|------|------|---------|
|
||||
| `apps/web/src/api/health/medicationReminders.ts` | CP-1: `time_slots` -> `reminder_times` | 字段名对齐 |
|
||||
| `apps/web/src/api/health/healthData.ts` | CP-2/CP-3: 字段名对齐后端 DTO | 字段名对齐 |
|
||||
| `crates/erp-health/src/handler/stats_handler.rs:59` | SEC-2: `health.patient.list` -> `health.admin.statistics` | 权限码升级 |
|
||||
| `crates/erp-server/src/main.rs:846-870` | SEC-1: CORS 双模式实现确认 | 生产环境配置验证 |
|
||||
| `crates/erp-health/src/dto/health_data_dto.rs` | CP-2/3 参照: 后端 DTO 定义 | 前端对齐基准 |
|
||||
| `crates/erp-health/src/dto/medication_reminder_dto.rs` | CP-1 参照: 后端 DTO 定义 | 前端对齐基准 |
|
||||
|
||||
## 附录 C: 与历史测试对比
|
||||
|
||||
| 指标 | 5月全系统测试 | 本次 V1 测试 | 变化 |
|
||||
|------|-------------|-------------|------|
|
||||
| 后端 API 通过率 | 100% (11/11) | 83% (40/48) | 覆盖面扩大 4x，发现更多边界问题 |
|
||||
| Web 前端通过率 | 100% (32/32) | 100% (25/25) | 稳定 |
|
||||
| 小程序页面覆盖 | 14 页面 | 66 页面 | 覆盖面扩大 4.7x |
|
||||
| 安全测试项 | 基础 | 18 项系统化 | 深度显著提升 |
|
||||
| 跨平台一致性 | 未测试 | 20+ 实体 x 3 端 | 新增维度 |
|
||||
| 发现 BUG | 0（1 误报） | 3C + 4H + 3M + 7L | 测试深度增加 |
|
||||
|
||||
---
|
||||
|
||||
> **报告结论**: HMS V1 版本在修复 3 个 CRITICAL + 1 个 HIGH 安全问题后，达到发布标准。建议执行修复后立即发布，随后按两周迭代计划推进 V1.1 优化。最紧迫的长期改进是建立前后端接口契约自动化检测，从根本上消除占历史 fix 量 24% 的接口不一致问题。
|
||||
Reference in New Issue
Block a user