作為前幾年一直在帶畢業(yè)設(shè)計(jì)和實(shí)訓(xùn)項(xiàng)目的開發(fā)我每年都會(huì)遇到一批選“人事管理系統(tǒng)”當(dāng)課題的同學(xué)。說句實(shí)在話人事管理系統(tǒng)是Java、Python、PHP畢設(shè)里出現(xiàn)頻率最高的題目之一最高的時(shí)候我?guī)У慕M里有一半人選了這個(gè)方向。但正因?yàn)樗Ｒ娝蕴貏e容易做淺很多同學(xué)交上來的所謂“系統(tǒng)”無非是套個(gè)后臺(tái)管理模板做了個(gè)員工增刪改查連登錄都做得不完整答辯時(shí)老師問一句“權(quán)限怎么控制的”“數(shù)據(jù)庫為什么這么設(shè)計(jì)”就直接卡殼。這篇就圍繞“基于Python的人事管理系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)”這個(gè)項(xiàng)目從整體設(shè)計(jì)、數(shù)據(jù)庫建模、后端邏輯、遠(yuǎn)程調(diào)試、論文配套到答辯準(zhǔn)備把一套能真正跑起來、也能扛住老師追問的完整方案講清楚。無論你是正在選畢業(yè)設(shè)計(jì)題目還是想拿Django做自己的第一個(gè)完整Web項(xiàng)目這篇文章都值得看完。我會(huì)盡量按真實(shí)的帶項(xiàng)目節(jié)奏來寫很多細(xì)節(jié)是教程里不會(huì)明說的。1. 內(nèi)容整體設(shè)計(jì)與思路拆解1.1 為什么人事管理系統(tǒng)適合當(dāng)畢設(shè)課題人事管理系統(tǒng)不是一個(gè)“有挑戰(zhàn)性”的題目但絕對(duì)是一個(gè)“有完整性”的題目。它天然具備一個(gè)Web系統(tǒng)該有的要素用戶登錄、角色權(quán)限、多表關(guān)聯(lián)、增刪改查、搜索篩選、數(shù)據(jù)統(tǒng)計(jì)、頁面布局。對(duì)畢設(shè)來說老師看重的不只是技術(shù)難不難更重要的是你有沒有把一個(gè)業(yè)務(wù)需求完整地落地。以Django實(shí)現(xiàn)的人事管理系統(tǒng)為例一個(gè)及格的版本至少要有三類角色系統(tǒng)管理員、普通員工。管理員可以維護(hù)部門信息、員工檔案、考勤記錄、薪資信息并且能看到系統(tǒng)的整體數(shù)據(jù)概況普通員工登錄后可以查看自己的信息、修改個(gè)人資料、提交請(qǐng)假或加班申請(qǐng)。別小看這個(gè)需求劃分很多同學(xué)交上來的系統(tǒng)里所有人共用一套界面、共用一套權(quán)限這在老師眼里基本就是“沒有設(shè)計(jì)”。從工作量來看人事管理系統(tǒng)也特別適合用Django快速實(shí)現(xiàn)。Django自帶Admin后臺(tái)、用戶認(rèn)證、ORM數(shù)據(jù)庫映射和模板引擎能讓開發(fā)量壓縮到很可控的范圍。而且它的MTV架構(gòu)非常清晰寫起來順手答辯時(shí)也容易講清楚——Model管數(shù)據(jù)、Template管顯示、View管業(yè)務(wù)邏輯面試和答辯都能直接順著架構(gòu)講。1.2 功能模塊與角色權(quán)限怎么拆拿到題目先別急著寫代碼第一件事是畫功能模塊圖。我自己的習(xí)慣是在紙上把系統(tǒng)拆成“前臺(tái)”和“后臺(tái)”兩塊。前臺(tái)面向普通員工功能相對(duì)簡(jiǎn)單登錄注冊(cè)、查看個(gè)人檔案、編輯個(gè)人聯(lián)系方式、查看工資條或薪資條目、提交請(qǐng)假/加班申請(qǐng)、查看公告通知。后臺(tái)面向管理員核心功能包括部門管理新增、修改、刪除部門設(shè)置部門負(fù)責(zé)人。員工管理維護(hù)員工基本信息包括工號(hào)、姓名、性別、入職日期、所屬部門、職位等?？记诠芾砉芾韱T錄入手動(dòng)考勤或?qū)肟记跀?shù)據(jù)員工端可以按月份查看自己的考勤。薪資管理設(shè)置基本工資、績(jī)效、補(bǔ)貼自動(dòng)計(jì)算實(shí)發(fā)工資員工端只允許查看本人的工資條。公告管理發(fā)布公司公告員工登錄后在首頁看到最新公告。數(shù)據(jù)統(tǒng)計(jì)簡(jiǎn)單展示員工總數(shù)、部門人數(shù)分布、男女比例等信息。權(quán)限控制這塊Django有現(xiàn)成的User模型和Group/Permission體系但直接用默認(rèn)權(quán)限模型在畢設(shè)里反而不夠直觀。我更推薦用一個(gè)is_admin布爾字段或者user_type字段來區(qū)分角色然后在視圖層做裝飾器或混合類判斷。對(duì)畢設(shè)來說這個(gè)方案更清晰講起來也更容易。1.3 為什么選Django而不是Flask或者直接上前后端分離每年都有人問我能不能用Flask寫或者用VueDjango做前后端分離。我的建議是除非你已經(jīng)很熟練否則別在畢設(shè)里為了炫技給自己加難度。Flask輕量是真輕量但正因?yàn)樘`活導(dǎo)致很多約束都要自己定。用戶認(rèn)證要自己寫session邏輯ORM要自己選SQLAlchemy還是別的Admin后臺(tái)更是完全沒有。Django則把這些都給你“打包”好了你要做的就是按照框架的約定把業(yè)務(wù)填進(jìn)去。對(duì)一個(gè)目標(biāo)是“完整交付一個(gè)系統(tǒng)”的畢設(shè)項(xiàng)目來說Django的上手成本反而更低。前后端分離的設(shè)計(jì)我同樣不建議非要用。引入Vue之后跨域問題、接口鑒權(quán)、Token管理、前端路由這些都會(huì)冒出來一旦中間某個(gè)環(huán)節(jié)卡住整個(gè)項(xiàng)目節(jié)奏就亂了。用Django的模板系統(tǒng)把頁面渲染出來配合Bootstrap或者Layui做樣式既能快速出效果又方便導(dǎo)師驗(yàn)收。前端用模板渲染和后端邏輯在一個(gè)工程里調(diào)試起來也省心得多。2. 核心技術(shù)點(diǎn)解析Django的MTV架構(gòu)與數(shù)據(jù)模型設(shè)計(jì)2.1 MTV架構(gòu)在人事系統(tǒng)里怎么落地Django的架構(gòu)稱為MTV即Model數(shù)據(jù)模型、Template模板、View視圖。很多同學(xué)學(xué)Django時(shí)背概念很熟但一輪到自己寫項(xiàng)目就忘了分層。我拿人事系統(tǒng)的“員工列表”舉個(gè)例子。路由層urls.py收到瀏覽器發(fā)來的/employee/list/請(qǐng)求把它交給對(duì)應(yīng)的視圖函數(shù)處理。視圖層從數(shù)據(jù)庫中讀取員工數(shù)據(jù)把數(shù)據(jù)打包成上下文字典傳給模板層。模板拿到數(shù)據(jù)后用Django模板語法渲染成HTML頁面返回給瀏覽器。整個(gè)流程中視圖層負(fù)責(zé)邏輯調(diào)度Model負(fù)責(zé)數(shù)據(jù)庫交互Template負(fù)責(zé)頁面展示各司其職誰也別越界。寫代碼的時(shí)候有一個(gè)很容易犯的錯(cuò)在模板里做復(fù)雜計(jì)算或直接調(diào)用數(shù)據(jù)對(duì)象的方法。比如有些同學(xué)會(huì)在模板里寫{{ employee.department.name }}這類深層屬性鏈雖然能跑但一旦數(shù)據(jù)為空就會(huì)報(bào)錯(cuò)而且不好維護(hù)。正確做法是在視圖里預(yù)先處理好把需要的數(shù)據(jù)組織成列表或字典再傳給模板。模板保持“傻白甜”狀態(tài)只負(fù)責(zé)展示這樣項(xiàng)目后期擴(kuò)展和維護(hù)都會(huì)很舒服。2.2 數(shù)據(jù)表規(guī)劃從業(yè)務(wù)需求到數(shù)據(jù)庫模型數(shù)據(jù)庫設(shè)計(jì)是整個(gè)項(xiàng)目的根基也是在答辯時(shí)老師非常喜歡追問的部分。我最常聽到的追問是員工和部門是什么關(guān)系考勤和員工怎么關(guān)聯(lián)工資結(jié)構(gòu)和員工是什么關(guān)系如果連這些關(guān)系都沒理清楚后面代碼寫得再漂亮也很難自圓其說。一份比較合理的人事系統(tǒng)數(shù)據(jù)模型至少包含以下幾張表數(shù)據(jù)表主要字段關(guān)聯(lián)關(guān)系用戶表User用戶名、密碼、郵箱、用戶類型與員工表一對(duì)一部門表Department部門名稱、負(fù)責(zé)人、聯(lián)系電話被員工表外鍵引用員工表Employee工號(hào)、姓名、性別、手機(jī)號(hào)、入職日期、職位外鍵關(guān)聯(lián)部門一對(duì)一關(guān)聯(lián)用戶考勤表Attendance考勤日期、簽到時(shí)間、簽退時(shí)間、狀態(tài)外鍵關(guān)聯(lián)員工薪資表Salary基本工資、績(jī)效獎(jiǎng)金、補(bǔ)貼、實(shí)發(fā)工資、月份外鍵關(guān)聯(lián)員工公告表Announcement標(biāo)題、內(nèi)容、發(fā)布時(shí)間、發(fā)布人外鍵關(guān)聯(lián)用戶請(qǐng)假申請(qǐng)表LeaveRequest開始時(shí)間、結(jié)束時(shí)間、事由、審批狀態(tài)外鍵關(guān)聯(lián)員工用戶和員工為什么單獨(dú)拆成兩張表因?yàn)榈卿浶枰馁~號(hào)信息和業(yè)務(wù)上的員工檔案信息關(guān)注點(diǎn)不同拆開方便擴(kuò)展也符合“一個(gè)賬號(hào)對(duì)應(yīng)一份員工檔案”的常見業(yè)務(wù)邏輯。一對(duì)一關(guān)系在Django里用OneToOneField實(shí)現(xiàn)。2.3 ORM模型代碼實(shí)現(xiàn)與字段選擇細(xì)節(jié)數(shù)據(jù)表設(shè)計(jì)好之后寫Django模型代碼就很直接了。不過字段類型和參數(shù)選擇有不少講究我建議按以下寫法來寫核心模型from django.contrib.auth.models import AbstractUser from django.db import models class User(AbstractUser): is_admin models.BooleanField(是否管理員, defaultFalse) class Meta: db_table sys_user class Department(models.Model): name models.CharField(部門名稱, max_length50, uniqueTrue) manager models.CharField(負(fù)責(zé)人, max_length20, blankTrue) phone models.CharField(聯(lián)系電話, max_length20, blankTrue) desc models.TextField(部門描述, blankTrue) class Meta: db_table hr_department def __str__(self): return self.name class Employee(models.Model): GENDER_CHOICES ( (M, 男), (F, 女), ) emp_no models.CharField(工號(hào), max_length20, uniqueTrue) name models.CharField(姓名, max_length20) gender models.CharField(性別, max_length1, choicesGENDER_CHOICES) phone models.CharField(手機(jī)號(hào), max_length11) department models.ForeignKey(Department, on_deletemodels.PROTECT, verbose_name所屬部門) position models.CharField(職位, max_length50) hire_date models.DateField(入職日期) user models.OneToOneField(User, on_deletemodels.CASCADE, blankTrue, nullTrue, verbose_name關(guān)聯(lián)賬號(hào)) class Meta: db_table hr_employee這里有幾個(gè)關(guān)鍵參數(shù)需要說明。on_deletemodels.PROTECT表示如果部門下還有員工就不允許刪除該部門這個(gè)對(duì)人事業(yè)務(wù)來說很有必要可以避免“離職后檔案掛在已刪除部門”的尷尬情況。而關(guān)聯(lián)員工賬號(hào)用blankTrue, nullTrue是因?yàn)樵试S員工暫時(shí)沒有登錄賬號(hào)不影響先錄入檔案再開通賬號(hào)的操作流程。GENDER_CHOICES用單字符存性別雖然簡(jiǎn)單但也要注意在模板里顯示時(shí)做映射轉(zhuǎn)換不能直接把M和F丟給用戶看。2.4 認(rèn)證授權(quán)與角色判斷的實(shí)現(xiàn)思路Django自帶的django.contrib.auth模塊已經(jīng)做了一大半的工作。登錄視圖它提供好了login_required裝飾器可以攔截未登錄用戶。我們要額外做的就是“區(qū)分管理員和普通員工”這件事。我推薦在自定義的User模型中加一個(gè)is_admin字段然后用一個(gè)自定義裝飾器來限制管理員功能。比如員工管理、部門管理、薪資錄入這些功能只允許管理員操作from functools import wraps from django.shortcuts import redirect def admin_required(view_func): wraps(view_func) def wrapper(request, *args, **kwargs): if request.user.is_authenticated and request.user.is_admin: return view_func(request, *args, **kwargs) return redirect(login) return wrapper需要注意is_authenticated和is_admin是兩回事前者表示有沒有登錄后者表示登錄的賬號(hào)是不是管理員。兩個(gè)條件都要判斷缺一不可。如果直接判斷is_admin未登錄用戶在訪問后臺(tái)頁面時(shí)會(huì)拋出AnonymousUser的屬性異常這個(gè)坑很多新手踩過。我個(gè)人不太推薦在這個(gè)項(xiàng)目里使用Django自帶的Group權(quán)限模型。它功能強(qiáng)大但配置復(fù)雜對(duì)只有兩種角色的畢設(shè)系統(tǒng)來說屬于殺雞用牛刀而且答辯時(shí)講起來會(huì)很繞。不如一個(gè)布爾字段走天下清晰明了。3. 核心功能的后端實(shí)現(xiàn)與頁面渲染3.1 URL路由設(shè)計(jì)與視圖組織方式Django項(xiàng)目的路由建議從全局到子應(yīng)用分兩級(jí)配置。在項(xiàng)目主路由里用include把各個(gè)應(yīng)用的URL分發(fā)下去。# project/urls.py from django.contrib import admin from django.urls import path, include urlpatterns [ path(admin/, admin.site.urls), path(, include(hr_system.urls)), ]在應(yīng)用內(nèi)部的hr_system/urls.py里再細(xì)分模塊urlpatterns [ path(, views.index, nameindex), path(login/, views.user_login, namelogin), path(logout/, views.user_logout, namelogout), path(employee/list/, views.employee_list, nameemployee_list), path(employee/add/, views.employee_add, nameemployee_add), path(employee/edit/int:pk/, views.employee_edit, nameemployee_edit), path(employee/delete/int:pk/, views.employee_delete, nameemployee_delete), path(department/list/, views.department_list, namedepartment_list), path(salary/list/, views.salary_list, namesalary_list), path(attendance/list/, views.attendance_list, nameattendance_list), path(announcement/list/, views.announcement_list, nameannouncement_list), ]視圖函數(shù)我還是建議用函數(shù)視圖FBV。Django的類視圖CBV雖然簡(jiǎn)潔但內(nèi)部邏輯像魔盒一樣出了問題新手很難排查。函數(shù)視圖一行行寫下來每一步都清清楚楚出錯(cuò)了也容易定位。高級(jí)用法等以后工作了再學(xué)不遲畢設(shè)階段求穩(wěn)最重要。3.2 登錄認(rèn)證與頁面裝飾器配合登錄邏輯一定要寫好因?yàn)檫@是系統(tǒng)的門面。我見過有的同學(xué)把密碼存成明文這真的是答辯災(zāi)難現(xiàn)場(chǎng)。Django的create_user方法會(huì)自動(dòng)對(duì)密碼做哈希加密但如果你用objects.create去建用戶就會(huì)把密碼原樣存進(jìn)去。正確做法如下from django.contrib.auth import authenticate, login def user_login(request): if request.method POST: username request.POST.get(username) password request.POST.get(password) user authenticate(request, usernameusername, passwordpassword) if user is not None: login(request, user) return redirect(index) else: return render(request, login.html, {error: 用戶名或密碼錯(cuò)誤}) return render(request, login.html)順便提一句Django默認(rèn)的User模型要求用戶名唯一如果出現(xiàn)“用戶名已存在”的報(bào)錯(cuò)可以去查一下是不是重復(fù)創(chuàng)建了賬號(hào)。還有一點(diǎn)登錄頁面本身不需要login_required裝飾器不然會(huì)出現(xiàn)“未登錄不能訪問登錄頁”的邏輯死循環(huán)。3.3 員工管理頁面的搜索、翻頁和條件查詢員工列表是后臺(tái)系統(tǒng)里用得最頻繁的功能也是老師重點(diǎn)考察的模塊。它至少要包含條件查詢、分頁展示、新增修改刪除這些能力。分頁用Django封裝好的Paginator就行查詢用ORM的filter條件組合。from django.core.paginator import Paginator def employee_list(request): employees Employee.objects.select_related(department).all().order_by(-hire_date) keyword request.GET.get(keyword, ) department_id request.GET.get(department, ) if keyword: employees employees.filter(name__icontainskeyword) if department_id: employees employees.filter(department_iddepartment_id) paginator Paginator(employees, 10) page_number request.GET.get(page) page_obj paginator.get_page(page_number) departments Department.objects.all() return render(request, employee_list.html, { page_obj: page_obj, departments: departments, keyword: keyword, department_id: department_id, })select_related這個(gè)是關(guān)鍵優(yōu)化點(diǎn)它會(huì)在查詢員工時(shí)用一條SQL把關(guān)聯(lián)的部門信息一次性查出來避免循環(huán)中反復(fù)查詢數(shù)據(jù)庫。員工數(shù)量少的時(shí)候感覺不出來數(shù)據(jù)一多性能差異就很明顯了。答辯時(shí)老師問到“你做過哪些性能優(yōu)化”這就是一個(gè)很好的切入點(diǎn)。搜索功能里還有個(gè)小細(xì)節(jié)使用icontains而不是containsi代表忽略大小寫。員工姓名不涉及大小寫但如果是搜索英文用戶名或拼音差別就出來了。3.4 模板頁面的繼承布局與表格型頁面設(shè)計(jì)Django模板最方便的就是繼承機(jī)制。建一個(gè)base.html作為整體骨架把公共的導(dǎo)航欄、側(cè)邊欄、頁腳都放進(jìn)去再用{% block content %}預(yù)留內(nèi)容區(qū)域。子頁面只需要寫自己的內(nèi)容部分就行。!-- base.html -- !DOCTYPE html html langzh-CN head meta charsetUTF-8 title{% block title %}人事管理系統(tǒng){% endblock %}/title link hrefhttps://cdn.jsdelivr.net/npm/bootstrap5.3.0/dist/css/bootstrap.min.css relstylesheet /head body {% if request.user.is_authenticated %} nav classnavbar navbar-expand-lg navbar-dark bg-dark div classcontainer-fluid a classnavbar-brand href{% url index %}人事管理系統(tǒng)/a div classnavbar-nav a classnav-link href{% url employee_list %}員工管理/a a classnav-link href{% url department_list %}部門管理/a a classnav-link href{% url salary_list %}薪資管理/a a classnav-link href{% url attendance_list %}考勤管理/a span classnav-link text-white-50{{ request.user.username }}/span a classnav-link href{% url logout %}退出登錄/a /div /div /nav {% endif %} div classcontainer mt-4 {% block content %}{% endblock %} /div /body /html列表頁的公共套路是“上搜索、中按鈕、下表格、底分頁”。搜索欄在一頭新增按鈕在另一頭中間一欄放篩選條件。表格列按業(yè)務(wù)字段排列每行末尾放“編輯/刪除”操作按鈕。這套布局在員工、部門、薪資、考勤頁面全部通用寫起來模式化但確實(shí)好用。這里有個(gè)容易被忽略的點(diǎn)模板里的{{ request.user.is_authenticated }}可以直接用說明request變量在模板上下文中是全局可訪問的。正因?yàn)檫@樣導(dǎo)航欄的“登錄用戶名”和“退出登錄”可以直接寫在base.html里不用在每個(gè)視圖函數(shù)里傳一遍省很多事。4. 項(xiàng)目交付配套Admin后臺(tái)、數(shù)據(jù)導(dǎo)出與遠(yuǎn)程調(diào)試配置4.1 Django Admin后臺(tái)注冊(cè)與定制有的同學(xué)習(xí)慣把Django Admin當(dāng)作畢設(shè)系統(tǒng)的主要管理界面這其實(shí)是個(gè)偷懶但又有效的思路老師也認(rèn)可。Django Admin在你執(zhí)行python manage.py createsuperuser后就能用登錄后臺(tái)就能操作所有已注冊(cè)的模型。為了讓Admin后臺(tái)更好用一般要注冊(cè)并配置列表顯示字段、搜索字段和過濾器from django.contrib import admin from .models import Employee, Department, Salary, Attendance admin.register(Employee) class EmployeeAdmin(admin.ModelAdmin): list_display (emp_no, name, gender, department, position, hire_date) search_fields (emp_no, name) list_filter (department, gender)Admin后臺(tái)雖然好用但我必須提醒一點(diǎn)老師的畢設(shè)要求如果明確寫了“系統(tǒng)至少要有前臺(tái)頁面和管理員后臺(tái)”那只用Django默認(rèn)Admin是可能被扣分的因?yàn)槿鄙僮灾髟O(shè)計(jì)頁面。比較合理的做法是把Admin當(dāng)作輔助管理工具主要功能還是自己開發(fā)的頁面。答辯時(shí)可以說“Admin后臺(tái)用于系統(tǒng)初始數(shù)據(jù)的維護(hù)業(yè)務(wù)功能在前臺(tái)頁面完整實(shí)現(xiàn)”這樣既體現(xiàn)了工作量又顯得思路成熟。4.2 薪資數(shù)據(jù)導(dǎo)出到Excel的實(shí)用方案人事系統(tǒng)里經(jīng)常需要導(dǎo)出報(bào)表手頭最方便的方案是用openpyxl庫在服務(wù)端生成Excel文件。from django.http import HttpResponse from openpyxl import Workbook def export_employee(request): wb Workbook() ws wb.active ws.title 員工信息表 headers [工號(hào), 姓名, 性別, 部門, 職位, 入職日期] ws.append(headers) employees Employee.objects.select_related(department).all() for emp in employees: ws.append([ emp.emp_no, emp.name, emp.get_gender_display(), emp.department.name, emp.position, emp.hire_date.strftime(%Y-%m-%d) ]) response HttpResponse(content_typeapplication/vnd.openxmlformats-officedocument.spreadsheetml.sheet) response[Content-Disposition] attachment; filenameemployees.xlsx wb.save(response) return responseget_gender_display()方法特別值得一提它是Django為choices字段自動(dòng)提供的方法用來把存儲(chǔ)值轉(zhuǎn)換成可讀文本。很多新手不知道這個(gè)就在代碼里自己寫一堆if判斷白白增加復(fù)雜度。導(dǎo)出功能雖然是小功能但在答辯演示時(shí)非常出彩能體現(xiàn)你完整考慮了業(yè)務(wù)實(shí)用性。4.3 遠(yuǎn)程調(diào)試配置本機(jī)連遠(yuǎn)程服務(wù)器的常用玩法畢設(shè)項(xiàng)目中“遠(yuǎn)程調(diào)試”其實(shí)是一個(gè)很實(shí)用的場(chǎng)景尤其是當(dāng)你把項(xiàng)目部署到服務(wù)器或?qū)嶒?yàn)室的機(jī)器上然后想在本機(jī)開發(fā)環(huán)境里打斷點(diǎn)排查問題。這里說的遠(yuǎn)程調(diào)試不是指網(wǎng)頁的遠(yuǎn)程訪問而是指PyCharm/IntelliJ系列IDE中的“遠(yuǎn)程解釋器Remote Interpreter”功能。它的原理是本機(jī)IDE將代碼同步到遠(yuǎn)端機(jī)器使用遠(yuǎn)端機(jī)器的Python解釋器來執(zhí)行項(xiàng)目斷點(diǎn)和變量查看都通過SSH通道來通信。這樣本機(jī)寫代碼、遠(yuǎn)端跑程序兩邊都能同時(shí)操作。配置方式分三步確保遠(yuǎn)端機(jī)器上的Python環(huán)境已安裝Django并用pip freeze requirements.txt把依賴鎖定。在PyCharm的Settings里找到Project: 項(xiàng)目名 Python Interpreter點(diǎn)擊齒輪選擇Add Interpreter On SSH填寫遠(yuǎn)端機(jī)器IP、用戶名、密碼再指定遠(yuǎn)端Python解釋器路徑。右鍵.py文件或Django的run配置選擇該遠(yuǎn)程解釋器運(yùn)行。IDE會(huì)自動(dòng)同步代碼到遠(yuǎn)端然后你在本機(jī)打的斷點(diǎn)會(huì)生效。有一點(diǎn)要特別注意本地代碼與遠(yuǎn)端代碼的目錄必須保持一致。聽著簡(jiǎn)單但很多人卡在這里表現(xiàn)為“代碼改了遠(yuǎn)端沒生效”或者“斷點(diǎn)進(jìn)了但是命中的行數(shù)不對(duì)”。確認(rèn)方法是在遠(yuǎn)端項(xiàng)目的__init__.py里打印一行print(os.path.abspath(__file__))看看實(shí)際運(yùn)行的路徑到底在哪再做映射調(diào)整。4.4 項(xiàng)目講解腳本與畢設(shè)答辯準(zhǔn)備很多同學(xué)做完項(xiàng)目但是講不清楚在答辯時(shí)被老師看成是“買了源碼而不懂原理”。準(zhǔn)備一個(gè)5到8分鐘的講解腳本非常重要。講解順序建議是從系統(tǒng)整體架構(gòu)開始依次說清楚系統(tǒng)用Django的MTV架構(gòu)、角色分管理員和普通員工、核心數(shù)據(jù)表有員工/部門/考勤/薪資/公告、重點(diǎn)功能有登錄認(rèn)證、員工管理、數(shù)據(jù)導(dǎo)出、首頁數(shù)據(jù)統(tǒng)計(jì)。然后現(xiàn)場(chǎng)演示一遍從登錄到看數(shù)據(jù)的流程。最后準(zhǔn)備好回答幾個(gè)高頻問題數(shù)據(jù)庫中員工和部門是一對(duì)多關(guān)系刪除部門時(shí)為什么用PROTECT而不是CASCADE密碼是怎么加密存儲(chǔ)的Django用的是PBKDF2算法加鹽哈希這樣的好處是什么你的系統(tǒng)有哪些安全性考慮login_required攔截未登錄訪問、防CSRF、參數(shù)通過ORM傳參防止SQL注入。如果一個(gè)部門下有50個(gè)員工列表頁打開會(huì)卡嗎用分頁和select_related來優(yōu)化。5. 常見問題與排查技巧實(shí)錄5.1 新手必踩的報(bào)錯(cuò)和解決方案速查這幾年代畢設(shè)的過程中每年都會(huì)遇上幾乎相同的高頻問題。我整理成一個(gè)速查表遇到類似情況直接對(duì)照處理。報(bào)錯(cuò)信息出現(xiàn)原因解決辦法Table xxx.hr_employee doesnt exist數(shù)據(jù)庫遷移未執(zhí)行運(yùn)行python manage.py makemigrations和python manage.py migrateTemplateDoesNotExist模板路徑配置錯(cuò)誤檢查settings.py中的TEMPLATES配置確認(rèn)模板文件放在應(yīng)用下的templates目錄NoReverseMatchURL別名寫錯(cuò)或視圖函數(shù)沒有對(duì)應(yīng)路由檢查模板里{% url %}的別名和urls.py的name參數(shù)是否一致NULL constraint failed: hr_employee.user_id新增員工時(shí)沒有處理用戶關(guān)聯(lián)為空的情況確保OneToOneField添加了blankTrue, nullTrueCannot assign must be an instance外鍵傳值時(shí)傳了ID而不是對(duì)象使用department_iddepartment_id直接賦值外鍵主鍵disallowed host未將訪問域名加入ALLOWED_HOSTS在settings.py中修改ALLOWED_HOSTS [*]或填寫具體域名Failed to load resource 403表單缺少CSRF令牌在模板form標(biāo)簽內(nèi)添加{% csrf_token %}這些問題看起來都很低級(jí)但每年都有人踩。尤其是makemigrations和migrate這兩步驟很多同學(xué)只執(zhí)行了一次后面模型改了忘記同步各種莫名其妙的數(shù)據(jù)錯(cuò)誤就來了。我的習(xí)慣是每次改完模型字段后就跑一遍這兩條命令形成肌肉記憶。5.2 數(shù)據(jù)處理上的三個(gè)隱藏大坑除了報(bào)錯(cuò)還有幾個(gè)不報(bào)錯(cuò)但結(jié)果不對(duì)的情況這類問題更隱蔽。第一個(gè)坑是外鍵刪除保護(hù)。部門刪除時(shí)如果用CASCADE會(huì)把該部門下所有員工一并刪除這在人事場(chǎng)景中是不可接受的。所以前面我在模型里用了PROTECT。但如果真的需要“先清空員工再刪部門”就要考慮先轉(zhuǎn)移員工所屬部門再刪除原部門這個(gè)業(yè)務(wù)邏輯在視圖層寫清楚。第二個(gè)坑是日期格式。員工入職日期如果直接從前端表單拿字符串?dāng)?shù)據(jù)格式可能是2024/09/01或2024-09-01Django默認(rèn)接受ISO格式的YYYY-MM-DD。安全起見可以用date類型的input控件配合表單校驗(yàn)或者在視圖里做一次datetime.strptime轉(zhuǎn)換解析失敗時(shí)返回友好的提示信息而不是直接拋500。第三個(gè)坑是薪資數(shù)據(jù)的安全訪問。員工只能看自己的工資條這是底線功能。如果視圖里寫了Salary.objects.all()然后把所有數(shù)據(jù)都渲染到模板那權(quán)限就形同虛設(shè)。標(biāo)準(zhǔn)寫法是if not request.user.is_admin: employee Employee.objects.get(userrequest.user) salaries Salary.objects.filter(employeeemployee)這樣做才能確保普通員工只能看到自己的數(shù)據(jù)。答辯時(shí)老師大概率會(huì)問“你怎么保證員工看不到別人的工資”這個(gè)代碼就是完整的回答。5.3 靜態(tài)文件丟失與部署后的頭像異常本地開發(fā)時(shí)python manage.py runserver會(huì)自動(dòng)處理靜態(tài)文件一旦部署到服務(wù)器上靜態(tài)文件就經(jīng)常出問題。最典型的現(xiàn)象是CSS樣式全丟了頁面變成“毛坯房”。解決方案是開啟Django的靜態(tài)文件收集功能# settings.py STATIC_URL /static/ STATIC_ROOT BASE_DIR / staticfiles # 部署前執(zhí)行 # python manage.py collectstatic執(zhí)行后會(huì)從所有應(yīng)用和靜態(tài)目錄中把靜態(tài)文件匯總到staticfiles目錄然后由Nginx之類的Web服務(wù)器接管文件的訪問。如果你選的服務(wù)器環(huán)境不熟悉最簡(jiǎn)單的方式就是把DEBUG False配合好用whitenoise中間件來托管靜態(tài)文件幾分鐘就能配置好。另外提一句如果項(xiàng)目里使用了ImageField上傳頭像或證件照那還需要配置MEDIA_URL和MEDIA_ROOT并在路由中加上static()臨時(shí)服務(wù)。很多同學(xué)只配了STATIC_URL圖片上傳后能存但頁面打不開就是這個(gè)原因。5.4 定制化開發(fā)的幾條實(shí)操經(jīng)驗(yàn)“源碼定制”在畢設(shè)中也很常見。所謂定制就是在基礎(chǔ)系統(tǒng)上增加或改動(dòng)功能。我的經(jīng)驗(yàn)是拿到別人的源碼后先不要急著看代碼先跑起來然后按以下順序熟悉項(xiàng)目先看README或項(xiàng)目說明文檔搞清楚運(yùn)行環(huán)境。用python manage.py runserver啟動(dòng)項(xiàng)目把每個(gè)頁面點(diǎn)一遍。在urls.py里梳理一遍頁面路由在models.py里梳理一遍數(shù)據(jù)表。搜索TODO或明顯帶作者需求的功能做標(biāo)記。改代碼時(shí)最忌諱的是直接改數(shù)據(jù)表結(jié)構(gòu)而不做遷移。比如加一個(gè)“緊急聯(lián)系人”字段正確步驟是先改models.py里的Employee模型然后執(zhí)行makemigrations、migrate再去視圖和模板里補(bǔ)充對(duì)應(yīng)展示。而且定制開發(fā)時(shí)很容易忽略頁面權(quán)限控制新加入了功能模塊結(jié)果所有人都能訪問這種低級(jí)錯(cuò)誤在驗(yàn)收時(shí)非常尷尬。6. 系統(tǒng)部署與版本環(huán)境踩坑記錄6.1 Windows與Linux環(huán)境的差異點(diǎn)畢設(shè)開發(fā)大部分同學(xué)用的是Windows部署服務(wù)器一般是Linux。環(huán)境切換之間有幾個(gè)差異點(diǎn)我第一次帶項(xiàng)目時(shí)都吃過虧。首先是路徑分隔符。Windows下路徑用反斜杠\Linux用正斜杠/。代碼里如果用Path(__file__).parent.parent這種模塊化寫法就沒事但如果寫死了./data\\file.xlsx一換環(huán)境就崩。其次依賴包版本要鎖定。requirements.txt里建議寫Django5.0.7這種鎖定版本號(hào)而不是Django5.0否則在另一臺(tái)機(jī)器上安裝的依賴可能因?yàn)榘姹静煌霈F(xiàn)不兼容。最后編碼問題在Windows上也很常見讀取文件時(shí)最好顯式聲明encodingutf-8避免中文亂碼。6.2 Django版本差異與“麒麟”環(huán)境適配這幾年職業(yè)院校和部分單位會(huì)用到信創(chuàng)環(huán)境比如麒麟操作系統(tǒng)配合ARM架構(gòu)的服務(wù)器。如果部署目標(biāo)是這種環(huán)境有幾個(gè)Django相關(guān)的適配點(diǎn)需要提前規(guī)劃。一方面Django本身是跨平臺(tái)的依賴的Python在Linux/ARM上也能正常運(yùn)行。但要注意Python版本別太新有些Django版本在特定的Python版本上會(huì)告警或報(bào)錯(cuò)比如Django 4.2和Python 3.10是一個(gè)比較穩(wěn)妥的組合。另一方面數(shù)據(jù)庫如果換成國產(chǎn)化的比如達(dá)夢(mèng)或人大金倉不能直接使用默認(rèn)的django.db.backends.sqlite3需要安裝對(duì)應(yīng)數(shù)據(jù)庫的適配驅(qū)動(dòng)并修改DATABASES配置中的ENGINE為相應(yīng)驅(qū)動(dòng)模塊。這類環(huán)境問題在答辯前最好先確認(rèn)清楚避免現(xiàn)場(chǎng)部署翻車。如果只是在軟件層面上用“麒麟系統(tǒng)”沒有替換數(shù)據(jù)庫和硬件架構(gòu)那Django項(xiàng)目基本不需要改代碼只需要注意Python環(huán)境的安裝方式。有的麒麟系統(tǒng)自帶的Python可能是3.6或3.8與Django新版本不兼容那時(shí)建議用pyenv或conda安裝指定版本的Python再創(chuàng)建虛擬環(huán)境運(yùn)行項(xiàng)目。6.3 讓系統(tǒng)可以快速移植運(yùn)行的幾個(gè)習(xí)慣一個(gè)好的畢設(shè)項(xiàng)目應(yīng)該做到“拿到源碼環(huán)境一配立刻能跑”。讓這步變簡(jiǎn)單我通常是這么做的用虛擬環(huán)境管理依賴項(xiàng)目根目錄放requirements.txt。數(shù)據(jù)庫文件用SQLite時(shí)確保.db文件路徑用相對(duì)路徑不綁定本機(jī)絕對(duì)路徑。自定義的配置項(xiàng)如上傳目錄、導(dǎo)出目錄都放到settings.py里不寫死在業(yè)務(wù)代碼中。項(xiàng)目根目錄寫一個(gè)README.md包含環(huán)境版本、運(yùn)行命令、管理員賬號(hào)、常見問題說明。關(guān)鍵代碼寫注釋但注釋只說“為什么”不說“是什么”。比如“這里用PROTECT是為了防止誤刪部門下員工”就很有價(jià)值而“給name字段賦值”這種廢話注釋我會(huì)直接刪掉。這些習(xí)慣會(huì)直接決定老師驗(yàn)收時(shí)對(duì)項(xiàng)目的整體印象。一個(gè)規(guī)范整潔、能一鍵跑起來的項(xiàng)目和一個(gè)代碼亂成一團(tuán)、還需要?jiǎng)e人幫你改配置才跑起來的項(xiàng)目分?jǐn)?shù)差距遠(yuǎn)比你想象中大。7. 一點(diǎn)不算總結(jié)的交代這些年帶過不少做人事管理系統(tǒng)的項(xiàng)目我也越來越覺得這類系統(tǒng)雖然看著普通但確實(shí)最適合用來練手和理解Web開發(fā)全流程。從需求分析、數(shù)據(jù)建模、后端邏輯、前端渲染到調(diào)試、部署、寫文檔、答辯每一步都是完整的工程體驗(yàn)。如果你接下來也要做這個(gè)題目我的建議很簡(jiǎn)單先花一天時(shí)間把功能模塊和數(shù)據(jù)表設(shè)計(jì)畫清楚再動(dòng)手寫代碼寫的時(shí)候把每個(gè)模塊拆開做做完一個(gè)測(cè)試一個(gè)最后留出三天時(shí)間專門處理部署和文檔。只要按這個(gè)節(jié)奏來哪怕中途遇到問題也完全來得及調(diào)整。最后分享一個(gè)小經(jīng)驗(yàn)也是我實(shí)際帶項(xiàng)目時(shí)才悟到的答辯時(shí)老師最在意的不是你用了多少技術(shù)而是你自己寫的代碼你能不能講清楚。所以就算最后參考了網(wǎng)上的源碼也要把每一個(gè)文件、每一處關(guān)鍵邏輯都過一遍改成自己的理解打上自己的注釋。那樣你站上講臺(tái)的時(shí)候才有底氣說“這個(gè)系統(tǒng)是我做的”。