第三次会议概览：
本次会议围绕 "FNBK" 项目展开，深入探讨了其内部社交功能、技术实现细节及性能优化方案。
小结
1、"FNBK" 项目介绍
- 该项目旨在重构银行内部员工的交友难题，通过H5端解决员工社交圈狭窄、信息发布不便等问题。
- 新增了"搭子"模块，用于发布和寻找搭子活动，如周末活动等。
2、核心功能与技术实现
- 内部专属与安全可信： 用户仅能通过银行内部APP嵌套登录；信息维护、活动发布等需管理员角色才能操作；个人信息（如手机号）在非互相关注时不会完全展示。
- 注册登录： 用户需输入工号或内部邮箱后缀进行注册，系统会调用内部API进行身份校验。
- 信息维护： 设计了信息完善度权重，影响用户在首页的排序；用户可上传多张照片；信息完整度会以百分比形式展示。
- 关注与互动： 区分了公开关注列表和 "默默关注" 列表；设有 "红娘" 角色，可为内外部用户提供搭子服务；用户可通过 "送花" 等方式互动，影响排名。
- UI与交互： 使用 Vant 组件库进行开发；关注列表和粉丝列表复用同一套组件；通过 rpx等单位进行移动端适配。
3、技术栈与性能优化
- 前端框架： 采用 Vue2，因其在银行内部环境经过验证，稳定性高。
- 状态管理： 使用 Vuex 管理登录状态、Token 等数据。
- 接口规范： 采用前后端协作的方式，通过 Swagger 文档定义和管理接口。
- 性能优化：
- 使用虚拟滚动加载大列表数据，提升首屏加载速度和滚动流畅度。
- 对首页图片进行压缩和格式转换（WebP），减少加载时间。
- 使用路由懒加载和代码分割，减少首次加载体积。
- 使用防抖、节流机制优化高频次的接口请求。
4、安全与数据处理
- 敏感数据： 用户密码等敏感信息在前端进行加密（如RSA），后端解密；传输过程使用HTTPS 保障安全。
- 图片安全： 前端对图片 格式 和 大小 进行初步校验，后端进行二次校验；项目未使用第三方服务进行图片敏感内容检测。
待办
1、下一个项目准备
- 张同学 需在本周五前完成下一个项目的整理工作。
- 老师 将在下周一上午10点安排下一个项目的面试。
1、简单介绍一下 "FNBK" 这个项目
FNBK（银行内部社交平台重构项目）
本项目是银行内部 老旧社交系统重构项目 ，原系统代码陈旧、维护成本高，本次基于业务需求与时间成本考量，仅重构 H5 端。
项目核心解决 银行内部员工 社交圈窄、信息发布不便、交友效率低 等问题，在原有功能基础上，新增 "搭子" 模块（由团队共同讨论设计），提升员工互动与匹配效率。
主要功能包括：
- 用户注册登录、个人信息维护
- 关注列表、动态发布、互动交流
- 搭子匹配、兴趣交友、高效脱单
整体目标是 优化内部员工 社交体验，帮助员工拓宽社交圈、提升工作生活幸福感。
2、你负责的这些模块当中，哪些功能最能体现内部专属和安全可信这种特点？
体现「内部专属、安全可信」的核心亮点
入口严格内部化 项目是 H5 嵌套在行内专属 APP 中，仅支持从行内 APP 单点登录 / 注册 ，外部无法访问，从入口上保证 仅限内部员工使用，杜绝外部人员进入。
权限严格管控 社交动态、搭子活动等内容 只有 管理员 或 拥有特殊角色权限的用户才能发布 ，普通员工 仅可浏览、参与，内容可控、可审核，保证平台安全合规、信息可信。
：入口隔离 + 权限分级 = 内部专属、安全可控。
3、注册登录模块中，您如何实现"仅限银行内部员工"的验证？
答案： 用户在注册时，需输入企业邮箱后缀或工号，前端将信息提交后端，后端与银行内部系统（如HR数据库）校验真实性。前端会提示用户输入正确的工号或邮箱，并展示验证进度。登录后，前端存储 token 和用户基本信息，用于后续身份识别。
注册登录模块 ------ 仅限银行内部员工验证
用户在注册时，需输入 银行工号或企业内部邮箱 ，前端将信息提交后端，后端 调用银行内部 HR 系统接口进行真实性校验 ，验证该用户是否为 在职正式员工 。若信息不合法，前端会提示用户输入正确的工号或邮箱；验证通过后，才允许完善个人信息并完成注册。登录成功后，前端存储 token 与用户基本信息，用于后续接口身份鉴权，确保只有内部员工可访问系统。
亮点：
- 明确：工号 + 内部邮箱双重验证
- 明确：对接 HR 系统 / 内部接口，不是随便校验
- 明确：在职员工才能通过（非常安全）
- 明确：token 鉴权（前端技术点加分）
这段 逻辑严谨、无漏洞、技术合理、完全符合银行项目
注册登录模块 ------ 仅限银行内部员工验证
我们这个项目是 银行内部专属社交 H5，嵌套在行内统一 APP 内部 ，采用的是 基于 工号的内部身份鉴权 + 免密自动登录机制。
入口唯一，外部无法访问用户只能从行内官方 APP 进入，外部没有独立入口，从根源保证只有内部员工可访问。
基于工号的自动身份验证 用户在行内 APP 已经 用工号完成统一登录 ，进入我们 H5 时，前端会 直接调用银行提供的内部身份 API ，自动获取员工工号、部门、姓名等核心信息 ，完成 免密登录。
首次进入：完善信息，不是重新注册 如果是 第一次进入 ，系统会判断为新用户，不需要手动输工号、密码，只需要补充：
- 昵称
- 性别
- 年龄
- 简单个人介绍
系统会 自动生成默认头像 （按性别区分），完成后直接进入首页。后台会把这些信息与 工号唯一绑定，确保一人一号、真实身份。
4. 严格内部鉴权，杜绝外部人员 整个过程 不支持手机号注册、不支持外部注册 ，所有身份必须通过 银行内部员工库 API 校验 ，只有工号合法、在职员工才能通过验证，保证平台 内部专属、安全可信。
精简一句话版（面试官问：怎么保证只有内部员工？）
我们是通过 行内 APP 单点登录 + 调用内部员工身份 API ，基于工号自动鉴权 ，只有在职员工能通过验证，不支持外部注册，首次进入只需完善基础信息，实现内部专属、安全可控。
这个版本 逻辑闭环、无漏洞、非常专业
4、信息维护模块包含了哪些核心字段？你是如何设计让用户愿意完善信息的？
信息维护模块核心设计
一、信息维护模块包含的核心字段
信息维护模块 主要分为 必填核心字段 和 选填补充字段：
- 必填项：姓名、性别、年龄、民族、学历、职业等基础身份信息；
- 选填项：身高、收入、兴趣爱好、MBTI性格、个人自我介绍等个性化信息；
- 风采展示：支持上传个人生活照、形象照等图片内容。
同时页面会做 非空校验，必填项不允许为空，保证信息有效性。
二、如何设计激励用户完善信息
主要通过 权重激励 + 视觉引导 + 互动反馈三个方式：
信息完整度权重机制 后台会根据用户信息完整度计算权重，信息越完整，首页列表排名越靠前、曝光越高，直接影响展示优先级。
完善进度条视觉引导 页面头部展示 信息完善进度条，直观显示完善百分比，引导用户逐步补全资料。
互动加分提升排名 加入送花互动功能，其他用户可送花点赞，收到的鲜花数量也会影响权重和排名；同时 上传照片数量也会提升权重比，进一步激励用户完善风采展示。
整体通过 "排名曝光 + 进度激励 + 互动加分"，让用户有明确动力去主动完善个人信息。
5、你的关注列表模块除了展示已关注的人，还需要展示哪些扩展的功能？
关注列表模块功能设计
一、核心展示内容
- 我的关注列表展示我主动关注的所有用户，支持查看对方头像、昵称、简介等基本信息。
- 私密关注（默默关注） 单独做了一个 不公开的私密关注列表，用户可以悄悄关注对方，关注关系仅自己可见，对方不会收到提醒、也看不到这条关注记录。
二、扩展功能
- 互相关注 / 回关功能借鉴抖音的交互逻辑，如果对方关注了我，在列表中会显示 **"回关" 按钮 **，可以一键快速互关。
- 取消关注 / 移除粉丝 支持对已关注用户进行 取消关注操作，也可对关注我的人进行移除管理。
- 快速跳转与互动点击列表中任意用户，可直接进入对方个人主页，查看资料、送花、进一步互动。
三、当前设计特点
- 区分 公开关注 和 私密默默关注，保护用户隐私与社交自由度；
- 重点突出 回关关系，提升用户之间的双向关注效率；
- 暂未设计系统级 "推荐关注"，更偏向基于已有粉丝关系的轻量化运营。
6、红娘牵线这个功能，它的具体流程是什么样的？前端如何配合红娘的操作？
红娘牵线功能流程及前端配合设计
一、红娘牵线功能具体流程
整体流程分为「红娘身份获取」「牵线操作执行」「牵线后管理」三个核心环节，同时区分银行内部用户与外行用户的不同规则，具体如下：
1、红娘身份获取（两种途径）
- 途径一：管理员直接分配角色，分配成功后，用户头像左上角会显示「红娘」专属标识符，明确标识身份；
- 途径二：用户自发申请，在「我的」界面有专门的申请按钮（图文样式），点击后提交红娘申请，等待管理员审批，审批通过后方可获得红娘身份，同时显示红娘标识。
2、核心牵线操作（区分内外行用户）
- 银行内部用户：可自行注册账号，注册完成后可直接在首页列表展示，无需红娘协助；
- 外行用户：无银行工号，无法自行在首页展示，需由红娘协助发布信息，发布后才能在首页列表呈现；
- 牵线核心：首页所有展示的用户列表，均需由红娘操作发布（内部用户自行注册后，也需红娘确认发布方可展示，或内部用户注册后直接展示、外行用户需红娘发布，核心是外行用户依赖红娘发布）。
3、牵线后管理
- 红娘拥有专属「牵线列表」，列表中可清晰查看自己帮助牵线的用户信息、牵线进度，以及该用户是否已脱单等状态，方便红娘跟进管理；
- 沟通限制：外行用户在首页的「联系」按钮，前端会显示「联系红娘」，而非「联系本人」，所有与外行用户的沟通需通过红娘中转，保障信息安全。
二、前端配合红娘操作的核心设计
1、身份标识可视化
- 红娘身份标识：在红娘用户的头像左上角，固定展示「红娘」标识符（图文结合），让其他用户快速识别红娘身份，同时也让红娘自身明确当前角色；
- 申请入口展示：在「我的」界面，清晰呈现「申请成为红娘」的按钮（图文样式，突出易点击），引导有意愿的用户提交申请，点击后跳转至 申请表单页面。
2、牵线操作支持
- 牵线列表开发：为红娘专属开发「牵线列表」页面，清晰展示牵线用户、牵线时间、脱单状态等核心信息，支持分页、筛选，方便红娘高效管理；
- 外行用户发布入口：给红娘开放「协助外行用户发布」的专属入口，表单中包含外行用户的基础信息、风采展示等字段，提交后直接同步至首页列表，前端同步更新展示；
- 首页列表权限控制：前端判断用户类型（内部/外行），内部用户注册后可直接展示，外行用户仅在红娘发布后才展示，未发布则不显示，确保首页列表的合规性。
3、交互逻辑适配
- 联系按钮差异化展示：前端判断用户是否为外行，若为外行，首页「联系」按钮显示「联系红娘」，点击后跳转至红娘沟通界面；若为内部用户，显示「联系本人」，直接跳转至一对一沟通；
- 审批状态反馈：用户提交红娘申请后，前端展示审批中、审批通过、审批驳回等状态，审批通过后自动显示红娘标识，同步开放红娘专属功能（牵线列表、外行发布入口）；
- 状态同步更新：牵线用户的脱单状态、牵线进度，前端实时同步后端数据，在红娘的牵线列表中及时展示，确保红娘能实时掌握跟进情况。
三、核心设计亮点（面试可补充）
前端设计核心是「适配红娘角色操作、区分内外行用户、保障交互流畅性」，既给红娘提供了高效的牵线管理工具，也通过差异化交互（联系按钮、发布权限），兼顾了内部用户的便捷性和外行用户的信息安全，同时通过身份标识、进度反馈，提升用户体验和红娘操作效率。
7、你是怎么去处理这种用户的隐私在前端展示的？比如说像这种手机号真实姓名
一、用户隐私在前端的展示处理（手机号、姓名、个人信息）
手机号脱敏展示 手机号不会完整显示，默认只展示开头和结尾几位，中间四位用星号隐藏 ，比如
138****1234。脱敏规则统一由 后端处理，前端只负责渲染展示，不做脱敏逻辑，保证安全统一。真实姓名与敏感信息控制 真实姓名、详细资料这类隐私信息，默认只展示 基础公开信息 。只有在 双方互相关注、互相收藏之后，才会展示更完整的个人信息；非互关状态下，只显示昵称、性别、大致信息，不暴露完整隐私。
二、消息次数限制与隐私提醒
为了进一步保护用户隐私、防止骚扰，系统设置了 默认消息发送限制：
- 非特殊关系用户，默认只能发送 10 条消息；
- 前端会实时展示 剩余可发送条数，比如 "您还可发送 X 条消息"；
- 达到上限后，无法继续发送，并给出友好提示，引导用户通过关注、收藏等正常方式建立联系。
三、前端层面的配合实现（面试加分项）
- 统一使用后端返回的脱敏数据，前端不存储、不拼接完整手机号；
- 根据用户关系（是否互关 / 收藏）动态控制信息展示区域，敏感模块条件渲染；
- 消息条数实时计数，达到阈值立即禁用发送按钮并给出提示，防止越权发送。
8、你的关注列表和粉丝列表是用的同一套组件吗？
关注列表 和 粉丝列表 用的是同一套公共组件 。因为两个页面结构、布局、列表样式基本一致，只是数据源 和展示字段 不一样，所以我把它封装成了一个 公共业务 列表组件。
通过传入不同的
type参数来区分，比如type=1渲染关注列表，type=2渲染粉丝列表，接口、标题、个别字段会根据类型动态切换。页面上方的关注 / 粉丝 Tab 切换，其实就是切换这个参数，重新请求数据并刷新列表，这样代码复用性更高，也便于后期维护。
9、信息维护中，用户上传头像的时候，你是怎么保证这个图片的质量和安全性的？
在用户信息维护上传头像时，我主要从 图片质量 和 安全性两方面做处理：
首先是 图片质量控制 ：前端会做严格的限制，头像上传的文件大小不能超过 20M，同时限制图片格式，只允许 PNG、JPG 这些常规格式，不符合格式或超出大小的文件直接拦截，不允许上传。另外项目里用了 Vant 的图片上传组件，它自带预览、压缩、格式校验等优化能力，能保证头像展示清晰、加载流畅。
然后是 安全性保障：上传前前端先做格式、大小的基础校验，避免无效文件请求；上传时使用正规的文件上传接口，配合后端做二次安全校验，防止恶意文件、非图片文件上传到服务器，确保头像上传功能安全可靠。
总结
- 质量：大小≤20M + 格式限制 + Vant 组件优化预览
- 安全：前端前置校验 + 后端二次校验，防止恶意文件
- 实现：基于 Vant 上传组件，简洁稳定、体验好
10、请描述一个完整的红娘牵线的业务流程在前端的一个体现
红娘牵线业务 ------ 前端完整流程
一、用户登录 & 进入个人中心
- 用户打开 APP / H5，进入 登录页
- 完成手机号 / 验证码 / 密码登录
- 登录成功 → 跳转到 首页
- 点击底部「我的」tab → 进入 个人中心页面
二、个人中心：展示「成为红娘」入口
在个人中心页面会出现一个 功能入口：
- 文案：成为红娘
- 状态：
- 未申请：可点击
- 审核中：显示「审核中」
- 已通过：显示「我的红娘中心」
- 已拒绝：显示「审核被拒，可重新申请」
三、点击「成为红娘」→ 红娘身份注册页
前端跳转到 红娘注册表单页，需要用户填写：
必填项：
- 姓名
- 性别
- 所属部门（可下拉选择）
- 联系方式（电话 / 微信）
- 自我介绍 / 红娘简介
- 服务区域（可选）
提交按钮：提交红娘申请
前端校验：
- 所有必填项不能为空
- 格式合法（手机号格式等）
四、前端提交申请 → 进入管理员审核流程
- 用户点击提交
- 前端调用接口，把表单信息传给后端
- 提交成功 → 前端提示：
- 「红娘申请已提交，请等待管理员审核」
- 页面自动返回个人中心
- 个人中心「成为红娘」入口状态变为：审核中（不可点击）
五、管理员后台审核（前端不操作，只展示结果）
管理员在管理后台进行审核：
- 通过
- 拒绝（可填原因）
审核结果会同步到用户端前端：
1. 审核通过
- 个人中心入口变为：进入红娘中心
- 前端推送消息 / 小红点：恭喜你成为红娘！
2. 审核拒绝
- 入口变回：重新申请成为红娘
- 可展示拒绝原因：如信息不完整、资料不符等
六、成为红娘后：红娘中心功能（前端核心页面）
审核通过后，用户点击「进入红娘中心」，可使用以下功能：
1. 发布 / 编辑 自己的红娘信息
- 头像
- 姓名
- 性别
- 所属部门
- 个人介绍
- 服务案例
- 联系方式
- 荣誉 / 资质等
信息越完整，权重越高，首页排名越靠前。
2. 帮伙伴提交资料（代用户发布）
红娘可以为身边人录入资料并提交：伙伴信息包括：
- 基本资料（年龄、身高、学历、职业、收入）
- 择偶要求
- 照片
- 自我介绍
- 联系方式（红娘可代填）
提交后进入资料审核，审核通过就会进入 首页匹配列表。
七、首页列表排名规则（前端展示逻辑）
前端展示用户列表时，按后端返回的排序规则展示：
1. 新人置顶规则
- 新注册 / 新发布的用户
- 默认 置顶展示 1 天（24 小时）
- 到期后自动恢复正常排序
2. 信息完整度排名（非新人）
- 信息完整度越高，排名越靠前
- 红娘自己的信息完整度也会影响其推荐权重
- 前端展示「资料完整度 X%」
八、前端状态总览（非常清晰）
- 未申请 → 可点击「成为红娘」
- 审核中 → 不可点击，显示审核中
- 已通过 → 进入红娘中心
- 已拒绝 → 可重新申请
- 红娘身份 → 可发布自己信息 + 代伙伴提交信息
- 列表展示 → 新人置顶 1 天 + 完整度越高排名越前
简短流程总结（方便给开发看）
登录 → 个人中心 → 申请成为红娘 → 填写资料提交 → 管理员审核 → 审核通过成为红娘 → 发布自己信息 / 代伙伴发布 → 信息完整度影响首页排名 → 新人默认置顶 1 天
11、你是如何与后端协作定义这个接口规范的？能不能举一个例子说一下？
一、你们真实的协作流程
先定页面需要哪些接口前端先看页面：红娘注册页、个人中心状态、红娘中心、列表页，先梳理需要哪几个接口。
前后端坐一起约定字段规范 比如：姓名用
name，性别用sex，状态用status，完整度用completeRate等，统一命名风格。后端按约定开发接口，写到 Swagger 里接口地址、请求方式、入参、出参、错误码全部定义好，发布 Swagger 文档。
前端去 Swagger 查阅、调试接口复制接口地址，按字段结构传参，做表单校验、状态处理、异常提示。
联调 + 统一规范字段对不上、逻辑不一致就同步修改，最终接口规范统一。
二、举一个最典型的例子：红娘申请提交接口
我直接按你们规范，写一套 前后端共同约定 → Swagger 体现 → 前端调用的完整示例。
1. 前后端先约定：这个页面需要 3 个核心接口
红娘申请流程，前端先提出需要：
- 获取当前用户红娘状态接口（个人中心展示用）
- 提交红娘申请接口（注册表单提交）
- 获取红娘信息 / 编辑接口（审核通过后用）
我们就拿第 2 个：提交红娘申请来举例。
2. 前后端约定字段（统一规范）
你们一起定好：
含义 字段名 类型 是否必填 姓名 name string 是 性别 sex int 是：1 男 2 女 所属平台 platform string 是 联系电话 phone string 是 自我介绍 intro string 否 服务区域 area string 否 统一规则：
- 小驼峰
- 状态用数字类型
- 字符串统一用 string
- 接口统一前缀
/api/matchmaker/xxx3. 后端写入 Swagger 文档（示例结构）
后端写完接口，Swagger 里会长这样：
接口基本信息
- 接口地址：
/api/matchmaker/apply- 请求方式：
POST- 请求类型：
application/json- 权限：登录后调用
请求参数（Request）
javascript{ "name": "张三", "sex": 1, "platform": "抖音", "phone": "13800138000", "intro": "专注同城牵线，靠谱高效", "area": "北京朝阳区" }响应结构（Response）
java{ "code": 200, "msg": "申请提交成功，请等待审核", "data": { "applyId": 10001, "status": 1 // 1审核中 2通过 3拒绝 } }错误码约定
- 200 成功
- 400 参数错误
- 401 未登录
- 500 服务器异常
4. 前端从 Swagger 查阅并使用
前端打开 Swagger 后：
- 复制接口地址
POST /api/matchmaker/apply- 按字段结构封装请求体
- 做前端表单校验：
- name 不能为空
- sex 必须选 1/2
- phone 格式校验
- 调用接口，根据
code做提示- 根据返回的
status更新个人中心按钮状态
三、再补一个：红娘状态查询接口（个人中心用）
也是你们真实会用到的，同样按规范来。
约定字段
- 用户 ID 自动带 token，不传参
- 返回红娘状态
matchmakerStatusSwagger 接口
- 地址：
/api/matchmaker/status- 方式：
GET响应
java{ "code": 200, "msg": "success", "data": { "matchmakerStatus": 0, // 0未申请 1审核中 2已通过 3已拒绝 "refuseReason": "" } }前端根据这个
matchmakerStatus控制按钮展示：
- 0 → 显示【成为红娘】
- 1 → 显示【审核中】
- 2 → 显示【进入红娘中心】
- 3 → 显示【重新申请】+ 拒绝原因
四、总结成你能直接跟团队说的话术
前后端协作调接口规范的流程就是：
- 前端先按页面拆接口，告诉后端需要哪几个接口；
- 前后端一起对齐字段名、类型、枚举值，统一命名规范；
- 后端开发完成后发布到 Swagger，把入参、出参、状态码写清楚；
- 前端去 Swagger 查看字段结构，按规范封装请求、做校验、处理返回；
- 联调过程中不一致的地方再同步修改，最终保持接口规范统一。
12、在团队的协作当中，如果遇到 UI 设计稿和在实践的时候有偏差，你会怎么去处理？
在团队协作里，如果遇到 UI 设计稿和实际开发效果有偏差，我一般是这样处理的：
- 首先严格按照 UI 给出的设计规范，把尺寸、颜色、间距、字体等样式属性直接应用到页面，先还原设计稿，再看实际运行效果。
- 如果发现还原后和设计稿偏差很大，或者在不同设备上显示不合理、交互体验不好，我不会自己随意修改，而是 先把问题整理清楚，比如标注哪里不一致、为什么实现起来有问题。
- 然后 先同步给项目经理 ，说明当前实现效果与设计稿存在偏差，以及可能影响体验的地方，由 PM 做整体判断。
- 如果确实是设计不合理、无法落地，或者交互逻辑有问题，就由项目经理统一介入，去和 UI 设计师沟通调整。
- 等 UI 修改完设计稿，项目经理确认没问题后，再把最终版给到我们前端，我们再根据新版设计统一调整页面样式，保证最终效果一致。
整个过程尽量 不跨环节直接沟通，避免信息混乱，同时保证产品体验、设计还原度和开发可行性三者统一。
13、你是如何保证这个接口联调的稳定性和数据一致性的？
在保证接口联调稳定性和数据一致性方面，我主要是这样做的：
首先，在开发前期，会先和后端一起沟通，明确当前页面需要哪些接口、每个接口的字段含义、类型、枚举值以及返回结构，提前把规范定清楚，避免后期频繁改动。
然后后端会把接口文档发布到 Swagger 或统一的 API 平台上，我会根据文档获取接口地址、请求方式、入参出参规范，再进行接口层的模块化拆分。
在项目里，我会按页面或业务模块统一管理接口，比如首页单独一个 API 文件、红娘模块单独一个 API 文件，所有请求统一封装、统一处理，不零散写在页面里。
这样做的好处是：
- 接口规范统一，不容易出现字段错乱、类型不匹配的问题；
- 后期接口改动时，只需要修改 API 模块，不用到处改页面；
- 请求和异常可以统一处理，比如 token、加载状态、错误提示，保证联调更稳定；
- 数据结构前后端提前约定好，能有效保证数据一致性，避免展示异常。
整体就是：提前约定规范 → 统一文档对接 → 模块化管理接口 → 统一封装请求，从而保证联调稳定、数据一致。
14、你是怎么处理用户在不同设备上登录同一个账号的这个数据同步的问题的？
关于 多设备登录同一账号的数据同步问题，我是这样处理的：
项目里主要使用 WebSocket 长连接 来做实时同步。用户在一台设备登录时，前端会先拉取 最后一次消息的时间戳，以此来展示最新数据；同时，当账号在新设备登录后，会通过 WebSocket 向其他已登录设备推送登出指令，另一端收到后自动执行登出操作，保证账号安全和数据一致性。
然后关于 测试相关：
做过 冒烟测试 ，也在真机上做过实际验证。项目经理会统一申请测试设备，一般是一台安卓三星手机或者鸿蒙系统的华为手机和一台 iOS系统的 iPhone手机，然后项目部署到测试服务器之后，我们会连接公司内部网络，在真机上进行登录、功能流程、页面展示等一系列冒烟测试，确保基础功能正常、没有明显问题，再进入后续测试环节。
15、如果用户反馈搭子活动报名未收到确认通知，你会怎么排查？
用户反馈搭子活动报名后没有收到确认通知，我会从 前端、网络、接口、后端、数据一层层逐步排查：
首先，我会先排查是不是 网络问题，比如用户网络不稳定、断连、延迟过高，导致报名请求没有正常发出去或者后端没收到。
然后，我会在前端进行排查。因为项目是 H5 页面，我会用手机端的 vConsole 这类调试插件，打开类似 PC 端 F12 的控制台，查看报名接口是否正常调用、请求有没有发成功、返回状态是不是 200，有没有出现接口报错、参数缺失或跨域问题。
如果前端调用一切正常，就会 同步联系后端同事一起排查：让后端查看接口日志，确认报名请求是否真正到达服务端、有没有报错、业务逻辑是否执行成功；再检查数据库，确认用户的报名记录是否正常写入，通知推送逻辑是否触发。
最后再定位是前端漏处理、接口异常、推送延迟，还是数据未入库，再针对性修复。
这样一套排查下来，基本就能快速定位问题所在。
16、你认为FNBK这个项目的核心价值是什么？
我认为 "FNBK" 这个项目的核心价值，主要体现在这几点：
一是为 银行内部员工提供一个专属的社交平台，方便大家拓展职场内外的社交圈，加强同事之间的交流与联系；
二是针对行内党员较多的特点，支持 党员活动的发布与组织，让活动通知更高效、传达更及时；
三是可以发布各类周末活动、兴趣搭子招募，丰富员工的业余生活，让活动组织和报名更便捷。
整体来说，项目的核心就是 打通内部信息传递渠道，拓展员工社交范围，让活动发布、组织、参与都更高效、更便利。
17、在这个项目当中你遇到的最大的挑战是什么？你是怎么解决的？
在 "FNBK" 项目里，我遇到的最大挑战是 iOS 端的兼容适配问题。当时页面结构是顶部搜索框 + 下拉面板 + 下方长列表，在 iOS 上一点击输入框唤起键盘，顶部搜索栏就直接被顶掉、错位，键盘收起后也回不到原来位置，布局完全错乱。
一开始排查发现是 iOS 对
fixed定位兼容不好，但项目页面已经开发得比较完整，重新改布局成本太高。我也想过跳转到单独的搜索页，但那样交互割裂，用户体验不好，就放弃了。后来我请教了公司其他组有经验的前端同事，结合他们的方案，通过 针对性的 CSS 样式兼容 + 设备判断 来解决：通过 JS 先判断设备系统，只在 iOS 环境下加载对应的兼容样式，动态调整定位和滚动行为，避免影响安卓正常表现，减少代码冗余。最终既修复了布局错乱问题，又不用大面积重构页面，顺利解决了这个兼容难题。
18、你是怎么确保用户上传的图片不含违规内容的？
关于用户上传图片的合规校验，我们项目是 前端基础校验 + 后端内容安全审核两层防护：
前端先做基础校验限制图片格式只能是 PNG、JPG、JPEG 等正常图片类型，限制文件大小，过滤非图片类型文件，拦截恶意文件上传，减轻服务端压力。
后端做内容安全审核（核心） 前端不具备识别图片内容的能力，所以 敏感图片、违规图片检测必须放在服务端。我们项目采用的是：
- 银行内部允许使用 腾讯云 / 阿里云内容安全 API，后端对接官方图片鉴黄、涉政、违规检测接口；
- 图片上传后先经过第三方安全审核，审核通过才会入库、对外展示，未通过直接拦截并提示；
- 如果是内网环境无法使用第三方云服务，就会使用 行内自建的图片检测服务，配置违规样本库做拦截。
内部项目额外管控虽然是银行内部员工使用，但依然会做安全校验，避免出现涉黄、涉政、暴力等违规图片，保证平台合规、健康。
最关键一句
前端只能做格式和大小校验，图片内容敏感识别必须由后端对接安全审核接口实现，这是行业标准方案。
19、
这家建筑类公司是我早期的项目合作方 ，当时是基于双方老板的资源协作，以项目合伙人 模式开展工作，当时为了简化项目对接流程，双方约定以这家公司名义签合作协议，实际办公、工作管理都在原互联网团队，属于内部资源协作。
山东SZ信息科技有限公司
